We have been building a single application in PHP for 18 years so you can imagine the legacy code and issues we are dealing with. I was looking for insight into more effective development and found your brilliant article. Thank you!
We started long before frameworks or some of the more modern languages and are saddled with some challenges. Seems like just the other day we were the new cutting-edge solution learning from the faults of the old DOS-based solutions we replaced.
W know we have to disrupt ourselves now and I'm expecting to learn a lot more here. I already have found some gems of wisdom on this site. Thanks again!
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
There's also a section in The Economics of Software Quality that deals with the quantification of the cost of technical debt. You can use the model to put a dollar estimate on the cost of not fixing the technical debt in your project and use that to get the resources you need from management to improve your code base. It's the best approach to technical debt I've ever seen and it might be worth the price of the book itself if your are having trouble getting the staff you need to pay down your debt.
Thanks for reading and good luck with your project.
Thanks Blaine, interesting to find someone with the same history.
We are currently very profitable (in percentage terms although we are quite small) and have been for about 10 years. OUr problem is we know our development of new features is too slow and we have to solve that. The competition is close on our heels and are running faster than we are.
Thanks again for the article and the additional info. Much appreciated.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Yes, a new competitor without all our technical debt was a worry that kept me up at night. It never happened but I brought up the possibility frequently to keep us focused on improving.
Rapid Development is definitely the book for you. The classic mistakes kill productivity. Eliminate them if you can so you can move faster.
Even if we don't get overtaken by technical debt (love that term by the way, yours?) we develop new features at a frustratingly slow pace and low quality.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Brilliant article!
We have been building a single application in PHP for 18 years so you can imagine the legacy code and issues we are dealing with. I was looking for insight into more effective development and found your brilliant article. Thank you!
We started long before frameworks or some of the more modern languages and are saddled with some challenges. Seems like just the other day we were the new cutting-edge solution learning from the faults of the old DOS-based solutions we replaced.
W know we have to disrupt ourselves now and I'm expecting to learn a lot more here. I already have found some gems of wisdom on this site. Thanks again!
Your story is eerily similar to my own.
My team and I found Modernizing Legacy Applications in PHP by Paul M. Jones to be an invaluable resource.
There's also a section in The Economics of Software Quality that deals with the quantification of the cost of technical debt. You can use the model to put a dollar estimate on the cost of not fixing the technical debt in your project and use that to get the resources you need from management to improve your code base. It's the best approach to technical debt I've ever seen and it might be worth the price of the book itself if your are having trouble getting the staff you need to pay down your debt.
Thanks for reading and good luck with your project.
Thanks Blaine, interesting to find someone with the same history.
We are currently very profitable (in percentage terms although we are quite small) and have been for about 10 years. OUr problem is we know our development of new features is too slow and we have to solve that. The competition is close on our heels and are running faster than we are.
Thanks again for the article and the additional info. Much appreciated.
Yes, a new competitor without all our technical debt was a worry that kept me up at night. It never happened but I brought up the possibility frequently to keep us focused on improving.
Rapid Development is definitely the book for you. The classic mistakes kill productivity. Eliminate them if you can so you can move faster.
Will definitely order the book.
Even if we don't get overtaken by technical debt (love that term by the way, yours?) we develop new features at a frustratingly slow pace and low quality.
Thanks again!
Just keep at it. It's a marathon, not a race.
"Technical debt"? Not my term. It's been around for years. I don't know who coined it.
The term "Technical Debt" was coined by Ward Cunningham.
Thanks for that. He coined it in 1992. Wow.