Sadly a lot of engineers have been indoctrinated into this mindset and I have had to fight quite many battles to conceive my fellow engineers that missing a deadline is not the worst thing in the world.
Then you've been fortunate to work at places that respect engineering.
Yes, I have. I have also worked at placed which do not. And the difference is night and day. The places which respect engineering are more fun to work at, deliver better features for less cost and the code is better. Only places which can deliver faster are crazy startups which constantly crunch time (I have worked at those too) but those are hell and the code is a mess.
The main cost I have seen at places which respect engineering is lower predictability. It is harder to budget and plan even if the end result in average is usually cheaper and always better.
The worst code I've ever written is because of shifting or unforeseen requirements. It doesn't matter how good the architect is if the foundation is built on sand.
100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I o…
> If the foundation is built on sand then that needs to be fixed.
Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.
I don’t think the underlying point is true: big companies don’t necessarily write bad code. A big company is like a collection of small companies. Code quality varies depending on where you are in it. Similarly, nothing leads me to believe small companies are any better. Some are excellent. Some are nightmare spaghetti.
Big companies oftentimes have cultures and leadership that lead to bad code.
100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I o…
> If the foundation is built on sand then that needs to be fixed. Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.
It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
The worst code I've ever written is because of shifting or unforeseen requirements. It doesn't matter how good the architect is if the foundation is built on sand.
100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I o…
I've worked on projects where if you wait for the requirements to be firmed up, you'll never be able to do anything. Depends on what you're trying to build if that means you need to stop and figure out the requirements or if you need to just deal with the shifting sands. Aircraft built for moving requirements don't work so well; but lots of things are fine with moving requirements. It'd sure be nice to know how users are going to use your product before you build it, but sometimes you build what you think is wanted, and people only use part of it or use it for different things than what was intended, and it's better to adjust and refocus than to start a whole new development process with the found requirements.