3 ms·
This. And also, code if this kind if 10x developers is often unmaintainable and untested, which brings 100x effort for their teammates in the future.
by viach 9y ago
This. And also, code if this kind if 10x developers is often unmaintainable and untested, which brings 100x effort for their teammates in the future.
- kpil 9y agoMy experience is that the long term effects are more than 10x. I heard a joke once : Complicated problems requires complicated solutions. Unfortunately, all problems are a bit complicated if you are a bit thick. The gist is that complexity grows faster than it needs. Ignoring people that can't make things over a certain threshold, there is a large group of programmers that can make things work, but are not able to build things clean enough or put in the effort required to build testable and maintainable code, simplify support and reduce runtime costs. Knowing when to stop and what to spend some extra time on is also important. I'll hesitate to add reducing future development costs, because I've seen too much overly complex code written in a misguided attempt to handle unknown future requirements. All these costs can easily build up to 10x over time. A factor is that a team probably smoothes over the effects of one or two bad coders in a way that it's not noticeable at short term - the code is delivered and the worst bits are plastered over, but the long term performance is reduced.
- honestoHeminway 9y agoAnother thing often happening, is features coming down to developers, who by slight alteration can be trivial to implement. This usually happens due to missing domain knowledge of the management and sales (and a lack of insight regarding this lack).
- kpil 9y agoI'd say it's a process error if the requirement specifications are locked at the point they reach a dev team. Preferably the requirements are explored by the team with the stake holders.