Auto Code

I got asked today for maybe the 50th time the following question about my job: “Well, can’t someone else at the office do that for you today?” The normal answer is “No, not really.” At this point one of two things happens. If it is someone who understands what I do they say “Oh” and move on. For most people though they stare at me like I just told them I’m the only janitor in the entire building who knows how to empty the garbage on the second floor. The bins there are made of plastic you know.

The problem it seems is in describing what an independent developer does. So I offer this analogy for how I see independent development.

The Auto

When a car company wants to build a car they get a number of teams together. You have people working on look, feel, performance, the motor, body, paint, and electronics. There are analysts who look at what the goals of this new car should be. These different groups have team meetings, inter-team meetings etc. They design the car, run simulations and commit it to schematics which are sent off to a plant for fabrication. The plant looks at them and decides what parts to make in house and what parts to have fabricated in various parts fabrication plants. As this is a large company they have factories that can make door panels or steering wheels. The parts makers ship the parts to the assembly plant who puts them together to make a car. The car (a prototype at this point) is then sent off to the testing teams who report back to the design groups who tweak the designs and the process starts over until you have a great product.

The Code

How does this in any way relate to what an independent developer does? An independent developer goes through all of these steps. The glaring difference is there tend not to be teams of people involved. The developer may be working on one piece of the greater puzzle, say the drive train of your vehicle or maybe a communications protocol library, in which case they have some input from others on what it is expected to do but they are doing it alone. The planning phase of the project happens in the developers head. There are no schematics drawn up (or maybe there are if the developer works that way, I don’t so for the sake of this there aren’t any), there are no meetings with other developers on how their project should be constructed.

With no schematics the developer does the assembly/production themselves. They have to look at what parts are available on the market, if they are cost effective and meet their needs, and if so how long those parts would take to work into their design. Not all the parts are on the market, in fact most of them are not. Those that are will fit, if the core design is modified some to make them fit. Those that aren’t the developer has to build themselves. The developer picks up his hammer and saw and starts building the parts, by hand. They are not normal parts, they are custom built, to the schematic in the developers head. Often the tools required to build the parts aren’t even available and the developer builds those too. Instead of fabricating all the parts and then putting it together like a car the developer builds the parts onto the product as he goes. This saves the final assembly step of the car since once all the parts are built or obtained the end product is done. It also means there are often no spare parts or breadcrumb trails to try and figure out what the developer was doing if they aren’t there to explain it.

Now the developer tests. Instead of testing with the testing team who is familiar with the product goals the developer tests himself, or worse with the customer directly. In the case where the developer is building one part of a big project he builds an test product to simulate how the large project will use his part so he can test his part. He does these tests on his own. Ideally he can test them with the consumer to get feedback but that has its own set of problems. Any tweaks that need to be made the developer makes until the product is ready for handoff to either the larger project or the consumer.

Conclusion

So, why is it so hard for someone else to step into the shoes of an independent developer? If you are on the car team, and you are in the “obtaining parts/building the test car” part someone else can look at the schematics and work with the engineers in the fabrication company, assuming they know how to do that sort of thing. If you are in the planning phase someone else on your team has knowledge about the goals and how the team is going to meet those goals.

How would this work in an independent code project? There are no schematics for some other developer to pick up on, no team meetings to draw on for information.  In order to do it they have to first disassemble what is already built, look at each part, figure out what it does in the grand scheme of things and sometimes how it was built in the first place. If the project is still in planning the situation is worse. Anyone trying to fill the developer shoes would have to have knowledge about what was already planned and discussed. They would have to be familiar with all the info the developer gathered through the planning process to this point. Worse if the original developer is coming back they would have to know them and their development process well enough to not say something they shouldn’t. It is cliche at this point how often a salesman will sell something impossible. This doesn’t just happen to salesmen. Anyone unfamiliar with a product can claim it does or will do something it doesn’t or can’t.

Don’t misunderstand me. Any other properly trained individual can step into an independent developer’s shoes. It has happened many times. The problem is the time and effort involved in someone else doing it. If the original developer isn’t coming back it is probably worth it. If they are coming back by the time someone else figured out what needs to be done the original developer is probably back and has finished the task and 5 others.

 

Leave a Reply