In the last post, I talked about the different factors that determine the cost of software development. In this post, I would like to highlight one in particular: context.

I recently inherited a project from another development team. I was handed the keys to the code and the cloud environment and had to stumble around in the dark to figure things out. I had to decipher how to run the code locally, debug issues, and improve on the existing solution.

Needless to say, it was a difficult task. However, I don’t think that most people realize how difficult, time-consuming, and error-prone it actually is. It isn’t a physical work like digging a ditch where I can take a shovel from one worker, hand it to another, and expect them to dig at the same pace. Software development is a creative work!

Software Parables

To help you relate, here are a few scenarios that I consider to be analogous:

The Mechanic

You are a mechanic and someone brings you a custom built car. They tell you that it is producing a bad smell and they want you to give them a quote on fixing it. You recognize many of the parts but many were custom machined and how they are put together doesn’t make sense.

The Author

You are a fiction author and someone brings you a book they would like you to finish. The book is in the historical fiction genre and is about 90% complete in their opinion. The publisher wasn’t happy with the previous author and would like for you to finish the book for their publishing deadline in two months. After a brief read, you recognize many of the main themes but are not sure how the author was planning to tie up their loose ends. It is also more like a rough draft and you question whether it is even 70% complete.

The Teacher

You are a math teacher and someone brings you a curriculum they would like you to finish. You are handed about 50 Word documents covering what appears to be basic algebra. However, the previous teacher seems to have been developing some innovative approach to teaching these topics and you aren’t sure what order they were intending to teach them in.

Why it Doesn’t Work (Well)

You can’t just hand off creative work by taking the physical parts of it and giving it to someone else. The physical product is only half the value at best. The other half, or more, is in someone’s head. You can transfer that knowledge but it is time-consuming and messy. Deriving that knowledge from the physical parts of the work, without talking to the author, is far worse.

In software development, these issues are accentuated by the fact that it is a very young field. So far less of it is standardized compared to other fields and it changes rapidly. Another problem is that it is hidden. It isn’t in a language people can understand or in a place where people can view it. This lack of visibility leads to people hiding messes. This is probably why most developers write sloppy code.

Solution

The best solution is to pick your development team well from the start and do what it takes to keep them around. Notice that I said “team”. If you put a solo developer on a project then you are introducing a lot of risks. Developers make better decisions when they have others to ideate with and this co-ideation enables multiple developers to maintain a mental context for the project that makes them efficient.

That is why at Induro we have the “rule of two”. We try our best to keep at least two developers on each project, even if it is an 80/20 split. This allows them to have the context to design together and perform meaningful code reviews to ensure quality. It also gives us a backup while someone is out and the ability to scale up quickly as the need arises.

Now sometimes you need to switch developers. This is easier if you have been consistently developing documentation in tandem with the code and if there is some overlap between the developers where the first can brain dump to the second. Just recognize the cost and the quality of the current system. Unfortunately, it is sometimes cheaper to build from scratch than to learn an existing system.