5 ms·

Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code

Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate. Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/ https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng... From The Unwritten Laws of Engineering, quoted in the article: Promises, schedules, and estimates are necessary and important instruments in a well-ordered business. Many engineers fail to realize this, or habitually try to dodge the irksome responsibility for making commitments. You must make promises based upon your own estimates for the part of the job for which you are responsible, together with estimates obtained from contributing departments for their parts. No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors." Also from the article: Avoiding responsibility for estimates is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.”

pydry 4y ago
If you deliver incremental improvements frequently enough people stop asking for promises, estimates and schedules. The reverse is also just as true, of course.
UK-Al05 4y ago
If you follow CD practices you will delivering working software all time. It doesn't mean you know what feature is going to be delivered in 32 weeks in the future though.
mfuzzey 4y ago
No one is talking about "never delivering any working software". You definitely do need to deliver working software and should do it in increments. That both shows the customer you are making progress and (more importantly) lets them adjust their requirements as they go along. Software is different from most other branches of engineering in that it is far less limited by physics and that the requirements are far harder to define. For example the requirements for a bridge or a building are relatively straight forward (size, load capacity, climatic resistance etc etc). That's not to say that designing the bridge or the building is necessarilly simple (though it probably is for small bridges and houses because we have centuries of experience with them) but even for complex construction projects the requirements are relatively simple even if the implementation may be very complex (think channel tunnel or mileau viaduc). In software there are much flexibility that most customers don't know what they want until they see it. They generally aren't capable of saying up front what they really want (and when they try to they are often wrong and end up saying "yes, that's what I said I wanted but now I can see it it's not good".
rrgok 4y ago
I almost agree with you. But I don't understand how is the programmer (Software Engineer) responsibility to produce code that hit production? This is the responsibility for project managers, product owners or whatever. Given the Software Engineer is not a one man team doing all other roles. This is like saying the UX/UI role is to decide what iteration of the design (as in visual) should be in production. No way!
- belfalas 4y ago
  > how is the programmer responsibility to produce code It is about mindset. Of course I do not mean that a programmer should suddenly be responsible for "doing everything." What I mean is, the programmer should have as their personal mission the writing of the highest possible quality code that is ready to go to production as quickly as possible with a minimum of rework. And crucially, you have to be able to provide a realistic and reliable estimate of when your work can be expected to be completed. This ability is gained through experience. Working well with project/product/design/etc. is part of being a good programmer. It is not enough to simply be a "good dev" - you must also be able to explain what your code does, why it does it that way, and any potential tradeoffs or flaws in design/implementation. If you cannot critique your own code in this way you are not a senior engineer. When you work with other people part of being senior is being willing to be held accountable. Hopefully this makes what I mean more clear. It is about mindset.
rrgok 4y ago
And to add: it is not the responsibility of the software engineer to deliver a product. This is like asking an actor to be responsible for release of a movie. Why the hell people keep expanding the role of a Software Engineer? Just stop this non sense already, please.

pydry 4y ago

If you deliver incremental improvements frequently enough people stop asking for promises, estimates and schedules. The reverse is also just as true, of course.

UK-Al05 4y ago

If you follow CD practices you will delivering working software all time. It doesn't mean you know what feature is going to be delivered in 32 weeks in the future though.

mfuzzey 4y ago

No one is talking about "never delivering any working software". You definitely do need to deliver working software and should do it in increments. That both shows the customer you are making progress and (more importantly) lets them adjust their requirements as they go along. Software is different from most other branches of engineering in that it is far less limited by physics and that the requirements are far harder to define. For example the requirements for a bridge or a building are relatively straight forward (size, load capacity, climatic resistance etc etc). That's not to say that designing the bridge or the building is necessarilly simple (though it probably is for small bridges and houses because we have centuries of experience with them) but even for complex construction projects the requirements are relatively simple even if the implementation may be very complex (think channel tunnel or mileau viaduc). In software there are much flexibility that most customers don't know what they want until they see it. They generally aren't capable of saying up front what they really want (and when they try to they are often wrong and end up saying "yes, that's what I said I wanted but now I can see it it's not good".

rrgok 4y ago

I almost agree with you. But I don't understand how is the programmer (Software Engineer) responsibility to produce code that hit production? This is the responsibility for project managers, product owners or whatever. Given the Software Engineer is not a one man team doing all other roles. This is like saying the UX/UI role is to decide what iteration of the design (as in visual) should be in production. No way!

belfalas 4y ago
> how is the programmer responsibility to produce code It is about mindset. Of course I do not mean that a programmer should suddenly be responsible for "doing everything." What I mean is, the programmer should have as their personal mission the writing of the highest possible quality code that is ready to go to production as quickly as possible with a minimum of rework. And crucially, you have to be able to provide a realistic and reliable estimate of when your work can be expected to be completed. This ability is gained through experience. Working well with project/product/design/etc. is part of being a good programmer. It is not enough to simply be a "good dev" - you must also be able to explain what your code does, why it does it that way, and any potential tradeoffs or flaws in design/implementation. If you cannot critique your own code in this way you are not a senior engineer. When you work with other people part of being senior is being willing to be held accountable. Hopefully this makes what I mean more clear. It is about mindset.

rrgok 4y ago

And to add: it is not the responsibility of the software engineer to deliver a product. This is like asking an actor to be responsible for release of a movie. Why the hell people keep expanding the role of a Software Engineer? Just stop this non sense already, please.