3 ms·

Time. Airplanes reuse and refine, reuse and refine the same system, more so with elevators. Software is often greenfield. Realistically, software projects get

Time. Airplanes reuse and refine, reuse and refine the same system, more so with elevators. Software is often greenfield. Realistically, software projects get budgeted for half/third of the time they actually need to be anywhere near complete. Then following the "delays" that should have originally been budgeted in, you might be over or under that more realistic estimation, but the software is worse for it. Why? Because the engineers were stressed/crunched/whatever into performing worse under the false pretense that "we're almost there," when that is not the case. If companies put a greater emphasis on correctness and budgeted time/money/testers/etc for it, things would be better. This low grade output is what the industry wants and that is what it is getting. People in charge of scheduling may say they care about correctness, they never really do, they care about fast and the appearance of some facsimile of function ("it looks like it works"). Imagine if you went to your higher up and said that the 6 month greenfield voting app, would actually take 1.5 years and require more resources just to ensure correctness. You would just get taken off the project. "It's just a voting app, one screen and server." But that misses the point, because it's a voting app, it needs to be hardened, just like an airplane. So you learn to shut up and either produce worse output, or work overtime to make something halfway decent. Either way it basically goes unnoticed until something blows up.

Frost1x 7y ago
It doesn't help that developers pretend this crap isn't going on either. Verbalize and acknowledge it but everyone's so worried that unrealistic requests and budgets are somehow actually realistic and they're just underperforming compared to their peers. So many actually suffering from imposter syndrome and worried that they're suffering from the Dunning-Krueger effect. Every group I've worked with seems to start in a defensive state projecting confidence but I casually admit to my struggles with everyone on the team and folks start to open up. By the end, you have a team of developers who can help set more realistic expectations. The less developers communicate amongst themselves honestly, the more they can be exploited by unrealistic expectations for development. It's a much nicer environment when everyone knows and admits they're slinging garbage code because of resource constraints than everyone pretending they're not.
taeric 7y ago
I think the greenfield aspect is deceptively responsible for so much damage. You want a good robotics engineer? Get someone that has made many robots. Want a good aeronautics engineer? Similarly, lots of aeronautics. Software engineer? We assume lots of software. But, this would be akin to assuming all of the other engineers were simply "mechanical engineers." To an extent, true. And there will undoubtedly be polymaths good at many. However, if you want someone to ship a Todo App on time, get someone that has done one before. A financial app? Same. ML Pipeline? Same. Instead, we get someone that succeeded at getting an app in some field out, and assume they know how to get the same in another field. And are then shocked when they are unable to estimate something they have never done before. Or why they spend their time shaving yaks that they know, without typically providing new value to their users. You want someone to do good at delivering what you are building? Make sure this is not their first time building it.

Frost1x 7y ago

It doesn't help that developers pretend this crap isn't going on either. Verbalize and acknowledge it but everyone's so worried that unrealistic requests and budgets are somehow actually realistic and they're just underperforming compared to their peers. So many actually suffering from imposter syndrome and worried that they're suffering from the Dunning-Krueger effect. Every group I've worked with seems to start in a defensive state projecting confidence but I casually admit to my struggles with everyone on the team and folks start to open up. By the end, you have a team of developers who can help set more realistic expectations. The less developers communicate amongst themselves honestly, the more they can be exploited by unrealistic expectations for development. It's a much nicer environment when everyone knows and admits they're slinging garbage code because of resource constraints than everyone pretending they're not.

taeric 7y ago

I think the greenfield aspect is deceptively responsible for so much damage. You want a good robotics engineer? Get someone that has made many robots. Want a good aeronautics engineer? Similarly, lots of aeronautics. Software engineer? We assume lots of software. But, this would be akin to assuming all of the other engineers were simply "mechanical engineers." To an extent, true. And there will undoubtedly be polymaths good at many. However, if you want someone to ship a Todo App on time, get someone that has done one before. A financial app? Same. ML Pipeline? Same. Instead, we get someone that succeeded at getting an app in some field out, and assume they know how to get the same in another field. And are then shocked when they are unable to estimate something they have never done before. Or why they spend their time shaving yaks that they know, without typically providing new value to their users. You want someone to do good at delivering what you are building? Make sure this is not their first time building it.