Couple reasons as answer for the question title:
1) deadlines (no time to polish/rewrite/refactor)
2) difficulty (clean code is hard)
3) clean code is somewhat subjective, so its hard to agree on specifics
4) because its hard, statistically, 50% devs are below the average, so its hard to expect them to produce top results
5) deadlines. nobody is paying for great polished code (mostly because its impossible to explain to them that its worth. And in MVP phase, its a good thing - you dont want to have clean code, because project might be killed in a month because it took too long to ship. Clients pay for features/projects.
Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
60% of a project's expenditures come in the maintenance phase of the project. I think more companies need to realize what a huge investment they are making. That's my favorite go-to to justify my position. That and handoffs to the next developer. Is this something you want to actually maintain yourself someday? Or are you going to keep on paying consultants $160/hr every time you need to make a change because you don't understand the code?
I suppose I don't quite buy into the whole MVP thing either. What good is it if I ship a product that sucks faster than anyone else? Users aren't going to be impressed when it is buggy as hell and they are paying to beta test things.
That's a very good point, I've also tried to use a similar one with management and at presentations. There is a very good book that can underpin this argument. Code Simplicity in its third chapter introduces the equation of software design which includes the effort involved in introducing a change. Not surprisingly for us, it talks a lot about how much maintenance costs matter in those efforts. I think it even goes further than 60%, but the point is there.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Couple reasons as answer for the question title:
1) deadlines (no time to polish/rewrite/refactor)
2) difficulty (clean code is hard)
3) clean code is somewhat subjective, so its hard to agree on specifics
4) because its hard, statistically, 50% devs are below the average, so its hard to expect them to produce top results
5) deadlines. nobody is paying for great polished code (mostly because its impossible to explain to them that its worth. And in MVP phase, its a good thing - you dont want to have clean code, because project might be killed in a month because it took too long to ship. Clients pay for features/projects.
60% of a project's expenditures come in the maintenance phase of the project. I think more companies need to realize what a huge investment they are making. That's my favorite go-to to justify my position. That and handoffs to the next developer. Is this something you want to actually maintain yourself someday? Or are you going to keep on paying consultants $160/hr every time you need to make a change because you don't understand the code?
I suppose I don't quite buy into the whole MVP thing either. What good is it if I ship a product that sucks faster than anyone else? Users aren't going to be impressed when it is buggy as hell and they are paying to beta test things.
MVP doesnt mean it has to suck. Quite the opposite. It has to provide value to the user that has a need.
That's a very good point, I've also tried to use a similar one with management and at presentations. There is a very good book that can underpin this argument. Code Simplicity in its third chapter introduces the equation of software design which includes the effort involved in introducing a change. Not surprisingly for us, it talks a lot about how much maintenance costs matter in those efforts. I think it even goes further than 60%, but the point is there.