Thursday, February 4, 2021

Starting Over

I read a thought provoking article:

How to hire senior developers: Give them more autonomy

It contains the provocatively titled section "Your Code is Worthless", and it makes a good case for this being true.  The context here is not that the running code is worthless to the business, but that the code itself is of no value to anyone else. i.e., Worrying about a competitor stealing your code base is pointless.

A basis of the argument is that the software engineering process is not about creating an artifact (the code base), but about building a "theory".  Another way to express this idea that I have seen is: the software development process is a group exercise in the organization of information.  The code is nothing more that the way to capture the outcome of that collaborative process.

To reach the conclusion that the resulting code is worthless, the article borrows from work by Peter Naur (of BNF fame) which says it is impossible for software, or its documentation, to encode all the information that was collectively organized and which is necessary to efficiently maintain it.  

There are a lot of good supporting details in that article, so it is definitely worth reading. Many of the points are aligned with my experiences.  The one conclusion that got me thinking is the premise that it is cheaper and faster to start from scratch than to try to adopt an unfamiliar code base. I do agree that this is true for a competitor getting a hold of other company's code. But could this apply to the company that owns the code?

What if a company had 100% turn-over of their developers, is starting over the best choice for the company?

Engineers usually tend to think a rebuild is the right answer in this case, but the business side never does. Is the business perspective wrong?

I have been in a situations where there was 100% turnover in a complicated code base.  I pushed to keep some of the previous developers on contract because I knew how crucial it was to leverage the information in their brains. Even if a rewrite was the right answer, this was not going to happen instantaneously and the business needed to keep operating. 

So maybe it is this continuity aspect that changes the equation.  If you have no choice but to figure out the code base, then a rewrite is only an added cost, not a replacement cost.

No comments: