Lone Wolf Developers

I'm a lone wolf developer, and I have yet to do work for a company that has a decent-sized engineering staff. So my standard contract spells out that my customer is responsible for testing.

My plan, should I need to execute it, is to swap or hire out review time from other local lone wolf developers. But that hasn't happened in the six years I've been in business, so I don't know that I need to worry.

:)))) And the point of your question is ?

In the case of the "lone wolf", good development is the question of attitude and experience. There are tasks for lone wolves and lone wolves for the tasks; the attempts to cover that under universal formalism would only cost a lot of time and money. (This doesn't mean the tasks don't have to be well thought) From the other hand, bulk of programming just has to be done; this is tackled by big disorganized crouds (which they call development teams). By the law of big numbers, crouds can't be all good, and this is where you have to enforce the religious ceremonies (ISO, MISRA or like) with associated overheads.

VLV

As ever Vlad has said pretty much what I was thinking in a much more robust and forthright way than I would have put it !!!

I don't do safety critical work but I have worked alongside such teams on automotive and aerospace projects. I have not observed that the IECs and ISOs in any way make up for the horrors introduced by the "big disorganized crouds" . Indeed I have always been amazed at the sheer lunacy and incompetence of a group comprised of indivduals who, taken one at a time, are sane and useful.

If I *had* to do code for a safety related system where I can't just pass it on as a black box to be tested I think the best bet would be to involve the customer at every level. If the customer can't accept that responsibility (ie has no competent people to use) then I would question the sanity of taking the work.

My worry with Tim's idea of sharing with other SPDCs is that the liability would be "joint and several" - ie any one party can be held responsible for the whole cost of an issue - I doubt if I could insure myself against that so the fee would have to be absurdly tempting.

Michael Kellett

I'm kind of glad myself that so far the issue is academic.

What it really boils down to for me is that even if I do my part 100% perfectly, there are an infinite number of ways that my customer can take that 100% good part and make a totally screwed up system from it. So I want to have a line in my contract that -- should things come to it

-- my litigating attorney can point to while saying "neener" to the client's attorney.

That depends on the (client) company, industry, application, etc.

Consider, most "Standards" are there to deal with The Unwashed Masses (for want of a better word -- and trying to avoid a flame war) that, left to their own devices, would just churn out "cruft" and hope for the best. They try to exercise some control over the process, syntax, etc. in the hope that "quality" (for want of a better term) will come along for the ride.

Of course, one doesn't guarantee the other! E.g., look at how arbitrary many "rules" are in coding standards -- how they often throw away the baby with the bathwater in the hope that these "restrictions" will improve the quality of the resulting product. I call it the "running with scissors" attitude -- rather than teaching people HOW to successfully run with scissors, let's just make it ILLEGAL to do so! (and hope that the consequences never bite us in the *ss)

Writing specifications is wonderful -- *if* the author is competent! Exhaustive testing is wonderful -- *if* the tester is testing the right things! Formal design/code reviews are great -- if the reviewers have critical eyes! Investigating the individual parties' qualifications makes sense -- *if* you assume a PhD is more qualified than a high school dropout. Everything is great - if the parties involved **care**!

I've started avoiding "whole projects" simply because of the time required. You've *really* got to have something unique to pique my interest *that* much! So much of most projects is The Same Ole Drudgery -- user interfaces, housekeeping routines, diagnostics, etc. Been there, Done that, Currently using the T-shirt as a dishrag... I don't know how some folks can do the same thing in the same company in the same industry year after year... :-/

Instead, I look for interesting subsystems that embody most of the cleverness in a project. I.e., testing some new technology -- or applying an existing one in a novel way. Or, a different way of interacting with a user, etc.

Barring that, I'll tackle a nice, self-contained subsystem -- like writing an MTOS or an RTOS and porting libraries to efficiently run on same. I.e., some project-within-a-project. Something that can easily be validated against its specifications.

It seems increasingly more common that I will have to design some particular I/O and write a suitable driver for same. I guess hardware skills must be a thing of the past (?). This is usually nice as I can easily prove the I/O behaves as intended "in a vacuum" so problems that the client may encounter afterwards are almost always examples of misuse on their part. (This makes it easy for client to fall back to my test cases to reassure himself that the hardware/driver actually still *does* work... "Gee, what am I doing differently if it doesn't?")

As to the legalities, I expect clients to "hold me harmless". I make no claims re: patent infringement (though I don't go looking for patents to infringe!). I guarantee there are no copyright problems with my code or hardware. And, I guarantee that it *works* as I claim -- and back this up with a "fixes are free" policy (i.e., it is in my best interest to make sure things work *before* the client gets them as anything thereafter comes out of my pocket!)

The industry plays a big role in how clients treat these efforts and compliance with them. E.g., my experiences with safety/liability issues have often involved large companies (or, small startups who intend to be bought-out by a larger company). Some are primarily concerned with "covering their *sses" (legally). Other industries are actually genuinely concerned with the "correctness" of the product. Curiously, the former are often bigger "sticklers" for procedure/conformance/etc. while the latter tend to be more interested in results.

I would be more interested in hearing the clients' take on all of this (I know what *my* clients have said). I.e., Users of Lone Wolf Developers.

The lone wolf (of which I count myself) is quite efficient. The only line was that every engineer spends 10% of their time talking to the other engineers. Thus a 9 person staff gets as much done as 1 engineer, and a 10 person staff get nothing done. This assumes that they all don't talk to each other at the same time.

b. Farmer

Ahhh! So _that's_ what meetings are for!

Lone wolf could be very efficient on the lone wolf's tasks (which are quite different from the main stream development tasks). However, the OP's question is how could the lone wolf provide an evidence that he follows best practices; as such evidence could be required by a customer who makes safety critical systems.

You have problems with math.

Classic assumption in the project management: if a project has to be coordinated between N developers, the communication overhead increases as N^2.

VLV

I think you said it above and nothing I added differed with that.

Could be. I guess I was more interested in making a joke than stoking my ego.

Turkeys flock while eagles soar.

Mark Walsh

I think you misunderstand (but maybe not, as your comment is cryptic). Bit Farmer made the point that with ten folks on staff, 100% of the time must be allocated to talking -- _unless_ they all talk _at the same time_.

Hence the meetings -- every one talks at the same time, then they go back and get a bit of work done before the conversations start up again.

I am getting the impression that, of those of you who are Lone Wolf Developers, none of you has had to consider whether you are following the standards or not. The gist of what I see so far is that you are all adhering to a specification worked out by the client and that it remains the clients responsibility for the safety aspects.

Where you are required to have independent review you get to use a network of similarly placed friends or aquaintances who can fulfil that function for you (paid or on a like for like basis).

However, you all seem to feel proud that what you do produce, for your clients, is of high quality and fully meeting the needs of your clients specifications, and is delivered in a timely fashion. Agreements you have with those clients ensures they accept the responsibility for the safety of what you produce.

From my own take, I have been the sole developer on a few systems where safety was definitely an issue. I managed to enlist a few people from my network who could assist with the review process and keep me honest about the quality and integrity of my designs (hardware and software). I have also been in the position of certifying the integrity and quality of software used in systems whose failures would be life threatening.

Throughout all of the experiences I have had, the systems developed during my lone-wolf years were of similar quality and integrity to those developed as an embedded person in a larger team (I have seen the situation it from both aspects).

For the record, the industry sectors I dealt with were in Transport (mostly rail) and Energy (mostly nuclear) for the most part with a couple of medical systems thrown in for good measure.

The reason I was asking you guys the question I posed at the start of this thread is because I am writing an article for the Safety Critical Systems Club newsletter (an unpaid endeavour) which observes that the standards I quoted all seem to imply a large company development process will be used. When you get to consider systems that must meet the SIL4 requirements it gets particularly onerous in the demands made. I just wanted a bit wider input of the experiences of a few others who might have looked on their work as contributing to the overall safety of their client's systems. I now have the feeling that I am in a smaller community than I originally thought.