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.
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.