44 ms·

I specialize in fixing bad software projects typically taking a role of principal developer/architect. Over nearly 20 years of my experience every rewrite I too

I specialize in fixing bad software projects typically taking a role of principal developer/architect. Over nearly 20 years of my experience every rewrite I took part in failed by either not delivering the improvements, by causing a lot of unplanned headaches for the business or by wildly missing all planned deadlines and cost estimates. On the other hand couple of years back I started purposefully taking up projects in bad shape and fixing them by cutting discussions about rewrites and instead focusing on putting work where it matters -- diagnosing the problems and finding solutions to them. I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. This is usually the cause why the application is in bad shape but more frequently than not the team will blame the organization, predecessors or constraints like old technology they are working with. They channel their frustration by focusing on the idea of the rewrite which seems like a relief from the frustration of current codebase. Unfortunately, the rewrite is performed using the same process that failed the previous version with predictable results. Think of a person that has messy house. This person does not have practice to keep things clean and in order. The person decides he/she will fix the issue by building another house and burning the old one with all belongings. The result is predictable. The solution is to learn to keep things clean and in order instead of burning the old house and re-building it at great cost and effort.

elliekelly 8y ago
> I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. Can you elaborate a bit more? Using your analogy I imagine this would be someone tidying up every evening before they go to bed. But can you maybe describe what it would look like/how the process might work for a team maintaining an application?
- deleted 8y ago
  [deleted]
Chyzwar 8y ago
I agree that in most cases it is the fault of an organization that problems were swept under the rug for far too long. There are cases were requirements changed so much over the years that architecture of system would no longer support the business without massive cost or overhead. We have plenty of ideas on how to build new software: agile, TDD, DDD. It seems that there is no proven process for doing rewrites.
- deleted 8y ago
  [deleted]
- lmilcin 8y ago
  I would not say in most cases organization is to blame, I would say in most cases the blame is shared.
lkrubner 8y ago
This sounds smart but actually makes no sense: "Think of a person that has messy house. This person does not have practice to keep things clean and in order. The person decides he/she will fix the issue by building another house and burning the old one with all belongings. The result is predictable." I believe your unstated epilogue is supposed to be something like "Rather than build a new house, it is best to learn how to take care of the one that you already have." Great. So let's suppose that happens. Now the team has a new skill. They've learned how to be organize their code and fix the problems in the code. So should they incrementally improve the code, or should they do a complete re-write? Your analogy does not stretch that far into the future. I agree with this, and I've had the same experience: "I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. This is usually the cause why the application is in bad shape but more frequently than not the team will blame the organization, predecessors or constraints like old technology they are working with." My sense is that what these teams need is new leadership. It doesn't really matter if their code is written in Fortran or C or Javascript or Go, what they need is good quality new leadership. Once they get that, their situation will improve. However, the new leadership needs to have the freedom to take the team in the direction of those skills and experiences that the new leadership has gathered over their lifetime. If the new leadership has a lot of experience in Ruby On Rails, then a complete re-write to Ruby On Rails can be justified, because if the new leadership is good, then they will produce something good in Ruby On Rails, and it will be better than what the old organization had before. And indeed, I think many real life re-writes happen because of exactly this set of circumstances.

elliekelly 8y ago

> I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. Can you elaborate a bit more? Using your analogy I imagine this would be someone tidying up every evening before they go to bed. But can you maybe describe what it would look like/how the process might work for a team maintaining an application?

deleted 8y ago
[deleted]

Chyzwar 8y ago

I agree that in most cases it is the fault of an organization that problems were swept under the rug for far too long. There are cases were requirements changed so much over the years that architecture of system would no longer support the business without massive cost or overhead. We have plenty of ideas on how to build new software: agile, TDD, DDD. It seems that there is no proven process for doing rewrites.

deleted 8y ago
[deleted]
lmilcin 8y ago
I would not say in most cases organization is to blame, I would say in most cases the blame is shared.

lkrubner 8y ago

This sounds smart but actually makes no sense: "Think of a person that has messy house. This person does not have practice to keep things clean and in order. The person decides he/she will fix the issue by building another house and burning the old one with all belongings. The result is predictable." I believe your unstated epilogue is supposed to be something like "Rather than build a new house, it is best to learn how to take care of the one that you already have." Great. So let's suppose that happens. Now the team has a new skill. They've learned how to be organize their code and fix the problems in the code. So should they incrementally improve the code, or should they do a complete re-write? Your analogy does not stretch that far into the future. I agree with this, and I've had the same experience: "I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. This is usually the cause why the application is in bad shape but more frequently than not the team will blame the organization, predecessors or constraints like old technology they are working with." My sense is that what these teams need is new leadership. It doesn't really matter if their code is written in Fortran or C or Javascript or Go, what they need is good quality new leadership. Once they get that, their situation will improve. However, the new leadership needs to have the freedom to take the team in the direction of those skills and experiences that the new leadership has gathered over their lifetime. If the new leadership has a lot of experience in Ruby On Rails, then a complete re-write to Ruby On Rails can be justified, because if the new leadership is good, then they will produce something good in Ruby On Rails, and it will be better than what the old organization had before. And indeed, I think many real life re-writes happen because of exactly this set of circumstances.