3 ms·

This bit articulates what I consider to be the main advantage of experience in programmers: > Often complexity is generated when there is no willingness to rec

This bit articulates what I consider to be the main advantage of experience in programmers: > Often complexity is generated when there is no willingness to recognized that a non fundamental goal of a project is accounting for a very large amount of design complexity, or is making another more important goal very hard to reach, because there is a design tension among a fundamental feature and a non fundamental one. It happens all the time that requirements are very complex. Junior programmers will fail to implement them. Better programmers will manage to implement them, but it'll take too much time to develop and especially to maintain their solution. 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. It's also why very large software projects fail, especially the type that is intended to save costs by replacing many different existing informal systems by a unified one. The requirements will be ridiculously complicated (have to do everything all the projects to be replaced do), and nobody in the software development part has the power to change the organisation first.

simonw 10y ago
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.
- Alex3917 10y ago
  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.
antirez 10y ago
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.
jeremyjh 10y ago
>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.
- teh_klev 10y ago
  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....
- codr4life 10y ago
  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.
dwc 10y ago
> 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.

simonw 10y ago

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.

Alex3917 10y ago
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.

antirez 10y ago

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.

jeremyjh 10y ago

>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.

teh_klev 10y ago
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....
codr4life 10y ago
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.

dwc 10y ago

> 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.