Hacker News Reader

> Experienced programmers recognize what's happening and have the personality to stand up the project leader and get a simplified version of the requirements accepted.

Some years ago I was tasked with taking a program and fixing a major bug and adding a new feature. The original devs were gone, the code base was a mix of spaghetti code and a large number of design pattern layers. I brought up rewriting it but was told no, absolutely not. After thrashing around the code for a while longer I rewrote it anyway, taking the requirements from our actual usage in production plus the desired new feature, and was done in short order with about 1/4 the LOC of the original. A lot of supposed requirements fell on the floor, but none of them were being used and some of them never belonged in that particular program at all.

For someone like me, a "normal" programmer, this is the only way to achieve bursts of 10x productivity. At that same job there was another like-minded person I collaborated with. As a nuts and bolts dev I was as good or better than he was, but his ability to cut to the chase and somehow convince management was almost magical. 10x doesn't come from typing in code very quickly on sub-tasks.

Exactly... working as a consultant in the past I saw there was this communication/personality problem. It gets both the experience to recognize there is a problem with one of the spec and the authority to say it and get a different proposal accepted. If the environment is hostile about proposals coming from programmers, a lot of bad things happen.

>The requirements will be ridiculously complicated (have to do everything all the projects to be replaced do),

One of the biggest problems in this type of project is that many requirements are unknown. Yes, the new system must do what the old system did, but no one can write down exactly what that is.

I'm working on a project exactly like this. I'm merging two billing systems. One of these is a legacy mudball of classic ASP and it's a veritable snake pit of nested includes and globally defined variables that just magic themselves into existence out of no-where.

It's been very hard to define tasks and timescales because there are little dark corners and special edge cases in the legacy mudball that don't immediately jump out at you when trying to review the code and work out what the hell it does, and why. The original developer is long gone and there's not much way of commentary in the code. A lot of the code is illegible because somehow the original dev's indentation went mad at some point in the past.

Then there's the database....

Oh, there have been plenty of attempts to write down exactly what that is. The problem is that more than half of it will inevitably consist of bullshit ceremonies, bike-shedding and marketing. Given enough experience to cut the right corners and knowledge about actual use cases for the old software, rewriting is not the horror story that's currently on auto-repeat.

Absolutely. This is why it's so important to have input from engineering during the product design stage of any new product or feature: good engineers can help spot when a minor change to the requirements could have a major positive effect on the overall system complexity and time to delivery.

Value scales exponentially with good design, costs scale exponentially with bad design.

This is the hardest thing to communicate to people running projects, in terms of why the amount of Python or Django or whatever that you know has very little to do with being a good or bad developer.