Some months ago, my boss asked me to add a feature to an unfamiliar source code written and maintained for a long time by another team, and I knew from one of my teammates who had resigned that its structure is overcomplicated and the code is outdated(library, framework, and language) and I myself reviewed that and disliked that also.

He treated it as a heritage and he had never reviewed it himself. I told him that I would spend more time navigating around the code(I didn't know tools like Sourcetrail at that time) than recreating the wheel myself. He agreed but looked unhappy.

Recently I read an article: How to hire senior developers: Give them more autonomy and learned from it that

One of Naur’s main conclusions is that making changes to an existing program (to accommodate changing requirements) is often more costly than writing new code from scratch, at least if done by people from a different team. This is because there are intangible aspects of the model/theory in the programmer’s heads, which can’t be expressed in code and documentation:
“A main claim of the Theory Building View of programming is that an essential part of any program, the theory of it, is something that could not be conceivably expressed, but is inextricably bound to human beings.”

Then I wonder if I was right? Can I just show this article to a boss in a similar situation in the future?

  • 1
    Were you right about what? Mar 20 '21 at 2:27
  • 2
    We can't possibly know if you were going to spend more time navigating the source code rather than recreating the wheel. Mar 20 '21 at 2:30
  • 1
    Not knowing the exact context and in my personal opinion, you were most likely right. But no, don't bother showing him that article. Sometimes, squishing expectations is an inevitable part of what a professional has to do. You can't make your boss happy all the time. Mar 20 '21 at 5:01
  • 1
    Hey, Joel, are you getting this? joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i Mar 21 '21 at 11:18
  • 2
    @DaveGremlin I can't believe that article is 21 years old... Which still makes it 14 years newer than the article referenced in the website above. Mar 22 '21 at 9:20

You can find an article that "proves" or "disproves" anything you want it to. Anyone, with any level of experience, can set up a website.

The industry is rife with people making statements they think to be globally true, with absolutely no room for nuance.

One of Naur’s main conclusions is that making changes to an existing program (to accommodate changing requirements) is often more costly than writing new code from scratch, at least if done by people from a different team.

Note, "often". Not always. The article you've linked to is itself referencing an article published in 1985. Even if everything written there was absolutely universally true then (it almost certainly was not) the landscape has changed in 35 (!) years. In that time, we have more expressive languages, which is clearer to understand, and code that is easier to modify.

I note that the author of the page you linked doesn't even bother to address this vital fact. Again, anybody can set up a website and write an article.

I'm going to bring this back to The Workplace. Should you show articles to your boss to justify your decisions? No, you shouldn't. You should spend effort trying to understand the articles, how the author has determined their opinions, and what factors has gone into that. Your manager doesn't seem equipped to do that, so you should do it for them.

There are a range of factors that can influence a decision making process. So even if you could absolutely prove that rewriting the code from scratch is faster, they may not be the best option.

I'm also going to refer you to a question you asked:

Would it be better if a tech leader explain his/her rules?

The answers stress that people that make decisions and rules should be able to justify them. Linking to an article is not a justification.

  • I just deleted my comment to repost it in lieu of editing it after the 5 minute barrier when you posted your reply. But yea that was my point (agreeing with you) - an article written 35 years ago does not contain learning from about half of the entire existence of the programming profession.
    – Player One
    Mar 22 '21 at 6:53
  • @PlayerOne It's amazing the author of the article just ignores this fact. The number one change in the industry is almost certainly how much more expressive languages have become. So changing existing code is much much easier than it used to be. A lot of other changes too though. Mar 22 '21 at 7:07
  • Exponentially larger code bases, good source control, exponentially more users, different delivery mechanisms, the existence of the internet, computers in every house, computers in our pockets... referencing one person's opinion on software development from the 80s is akin to saying an ancient Roman understands more about tall buildings than a manager at a modern architecture firm (in my opinion). They were masters who created exceptional buildings, but the world has dramatically moved on.
    – Player One
    Mar 22 '21 at 7:40

Before recreating the wheel, I recommend doing at least one pass of maintenance on the current code. Why? Because there are often subtle things hidden in the current code that are not documented and are relied upon by users of that code.

In my experience, using the first pass to do a better job of documenting what that code does will greatly enhance any effort to recreate it. Once you fully understand the code, then recreating it will be much easier, go faster, and have fewer bugs. You will be better able to build all the important unit tests.

Secondly, recreating the wheel is best done when you can walk in with a list of enhancements that the users want. It is harder to get that list unless you have worked with that code and its customers.

Not the answer you're looking for? Browse other questions tagged .