Our industry is famous for delivering projects late and over budget. Many projects are cancelled outright and many others never deliver anything ne...
For further actions, you may consider blocking this person and/or reporting abuse
Most of the low quality projects I have worked on have had thoroughly demotivated devs.
Usually combined with lackluster management and sometimes a serious case of toxic dev culture.
I’ve become a nudger to try and counter, refactoring things, casually suggesting code improvements, and poking the culture with talks and genuine respect for the people going through change. There is always the risk of pissing someone off if you don’t weigh your words, so respect is key.
It’s hard to be consistent tho, especially if you repeatedly fail to get ideas across to a tough crowd...
Thanks for your comments, Sebastian.
Has your "nudger" approach been successful?
I'm also interested in hearing about any defect measuring systems on any of your projects. Did you measure things? Does measuring defects change anything?
Do projects that do measurements have better outcomes in your experience than projects that don't or projects that do a poor job with measurements?
It works in my immediate surroundings, i managed to get several old complex systems refactored by doing it, the business value here being increased application performance and feature output.
I remember distinctly one place where we took bugs quite serious. We had a hard limit of ~15 bugs of varying severeties, any more than that and bugs would get higher priority relative to new features.
It was quite efficient, after implementing it, we definitely had less bugs on production.
I'm not sure if it was the measuring of just the proper focus they received that did the thing, but it definitely did something.
That's great. I'm glad it worked for you.
I've tried to be a "nudger" too and it definitely helped by my projects also suffered from some of the 36 classic mistakes so we never went as far and as fast as I would have liked.
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.
This Is such a great article! Seriously, awesome!! Five stars!!
I have a question: do you think that, nowadays, using always tools(frameworks, for example) which have few years of life, Is a plus to developing low quality software?
Talking to a friend, an engineer from another industry(chemical), told me something that i consider really interesting:
"You, the developers, do something weird, from the engineer perspective: always using tools that just came out few years ago. In my area, we dont change anything(machinery, pieces, nothing) for something that haven't been tested for several years. Maybe because error in my area are more expensive than yours, maybe mistakes in software development are cheaper to solve and with minor consequences"
Do you think that industry should wait a little bit more before using all of these new frameworks?
The people in our industry are prone to adopting the new, trendy thing for all the wrong reasons. And I'm not taking just about frameworks. It also includes languages, methodologies, libraries, tools, management fads, and more. If it's new and it's got buzz we're trying it in production systems regardless of what our stakeholders think. Read You Should Build your Next App on a Boring Stack for more details.
If the stakeholders in most projects considering a new technology were consulted in a meaningful way most of them wouldn't want the risk of new and shiny. Most projects need risk reduction and schedule predictability more than they need innovation in their stack.
As a manager, I've shot down many proposals like this. The devs don't like it but I tell them that we are here to make money and meet management objectives and that they should experiment with any technology they want on their personal time.
I'm not saying that we never do anything new but my default answer of "no" to the shiny and new thing keeps us from changing without a good reason.
I think you've brought up another important dimension here. The engineers building a chemical processing plant have an expected lifetime in mind that's likely several decades. They are being paid to make sure the plant is maintainable for it's entire anticipated operating life. I've rarely met a software developer that even considers that.
On one project I worked on we had an explicit expected lifetime of 15-20 years. So every time we looked at adding a new library or tool we considered the probability that it would still be around in 20 years and what we would have to do if it wasn't. That consideration radically changed our decision making process--we became much more conservative.
I think engineering and Software development are very different areas, so it's hard to draw comparisons. Development cycles tend to be longer in the area of engineering (even though there are exceptions from this rule to be found, like rapid prototyping in engineering and maybe SAP for software). I think this has also to do with the scale and complexity of the projects and companies involved. Let's take a new car from a big manufacturer and a new app from a small Startup for example. The bigger the complexity of a project, the bigger the transaction costs of innovation. While every part of the car needs to work reliably in order to avoid huge costs down the line, a small software company often needs to be fast, the costs of an error are smaller, so there is more room and also a bigger need for innovation.
Have been fighting these battles for 35 years... Win some, lose most. While I currently specialize in test automation I've long championed various approaches to build quality into the project. Have seen all of the 36 mistakes and tried jawboning corrective action for each.
Am stilling hanging in there!
Superb article! Thanks!
Thanks, Patrick. Could I ask you to draw on your experience and share one or two tips with us to help devs in similar situations improve quality?
What's worked the best in your experience? Are there certain arguments or changes that have above average success rates in your experience?
Paying attention to user/customer needs and making sure they are understood helps a lot.
Not trying to do too much at one time (what I think agile really tries to address) also makes a difference.
Keeping iterations short and keeping the customers in the loop seem to be critical and cover a significant chunk of the infamous '35'.
And doing some 'design': thinking (and conversing) about what is to be delivered and about ways to do it before jumping into code. Can take ten minutes or a couple days, but is important.
If I keep going I'll rehash all 35. . .
Excellent article!
I come to the same conclusion but from a slightly different angle (even including the developer-in-crappy-company problem): dev.to/mbjelac/stop-the-madness-14f6
An article I reference is Martin Fowler's Is High Quality Software Worth the Cost? which discusses the very same topic as your article.
As a TDD enthusiast I particularly found interesting your mention that testing (after development) is largely ineffective, contrasted to test-prevention techniques (TDD included) which are not.
Thanks for this great article!
I read your links and I largely agree. I've seen lots of articles like Fowler's. They make their case with logic and appeals to common sense, which is okay but I wanted my article to be backed by data. It took a while to find these books and it took even longer to read them but I'm happy with the results.
Depending on exactly what you meant with your TDD comment, I don't think the authors of either book would readily agree. If you have a low quality development process on two teams and one team does TDD and the other team writes their tests after they write their code, you probably won't see much difference in the quality of the final product. It will be low in both cases. After all TDD won't catch requirements errors, which account for about 60% of the delivered defects in most projects.
But TDD could be a beneficial component of an overall quality program that stresses defect prevention and early defect detection and removal. That kind of development strategy will likely produce higher quality software than a team that focuses on a more informal development process and then hopes to find and fix defects to drive quality into their project at the end.
Cheers.
I agree with your view that TDD alone isn't enough. I suppose that by TDD you mean unit (micro) level TDD.
I use the term more broadly to include the BDD process - a form of requirements gathering which ensures (at least) that:
I'd assume micro-level TDD as well but the authors didn't specify. BDD existed in 2011 (when the book was published) but just barely and it wasn't very popular yet.
Even though I was pushed back by the clickbaity title, I must admit tat this was a very interesting read. Throughout the years I've experienced a lot of the problems mentioned again and again. The bigger the project the more important it gets to have good conventions about which hopefully everybody is on board, automated tools to assist you on the way, and processes to share knowledge and to allow for reflection and improvement. And while it might work out on a smaller scale, rushing things on big projects is the worst as it tends to backfire many times over.
Yes, Johannes, the authors of The Economics of Software Quality repeatedly make the point that larger projects are disproportionately more difficult to manage successfully than smaller projects.
Why do you think people resisted adopting enough process to ensure success on larger projects you've worked on?
The chart uses black graphics and a transparent background making it difficult to read on dark themed Dev.
Was also about to comment this. Can a white background be added to the image?
Ah, I didn't think of that. I'll fix it.
Dark theme = best theme. Thanks much. I've added it to my list to read later so I'll check back later.
Fixed.
Thanks!!
One of the biggest problems with this is that it centres around a single keystone in-depth study. It was an interesting choice but I'm not sure I could give it to our product & eng teams to improve their work.
I'd agree with you if that were true but it's not.
I chose to focus this post narrowly because it's such a big topic and it seemed like a good idea to focus on the strongest evidence. But there are many, many studies backing up this conclusion from many different angles.
Rapid Development contains extensive footnotes so you can look up all those studies.
But you don't have to take anybody's word for anything. Every team should probably be measuring their ROI (results divided by effort) in whatever way is meaningful to them and doing experiments to improve it given how costly software development is.
I'd be shocked if you found your team is more efficient/economically productive if you focused less on defect prevention, pretest defect removal, and the 36 classic mistakes and more on testing, debugging, and rework. But I suppose it's possible.
Cheers.
Whoa there... I never said that, I said this write-up focused on a single keystone.
I did not state if it was wrong or right, just that the article itself doesn't provide dev teams the tools to reduce.
FWIW it was merely a call out to think about action items, not down your work or the concept of the article.
I think other works such as boringtechnology.club/ offer more clearly actionable alternatives which focus.
Apologies, Lewis. I didn't mean to put words in your mouth. It's easy to misinterpret blog comments.
I read your link and I agree with the author's conclusions on the benefits and costs of adding technologies to your stack. But I'm not sure how that relates to the topic of my post. Can you help me understand the connection?
A long read. I will be going back to this post from time to time. It is sad that:
Forget about improving quality at the project level and conform to the norms of your team
is an option for some of us.
I know. It pained me to write that. But it's true.
You wouldn't believe how often I've interviewed people who have told me that their project managers wouldn't let them write tests, do code reviews, or engage in other reasonable QA activities--because they're a "waste of time."
Linux is a good example a memory-unsafe language doesn't automatically lead to disaster. I think the issues with Microsoft Windows exist because of corporate policies and many bad practices enforced by the management. If you read blogs written by ex Microsoft devs you know what I mean.
I saw many open source projects implemented in C or C++ which sport quite a high quality level.
That said, this article is the single most useful one I ever read on the subject of software development! (I'm in the industry for 20 years now and currently working as an IT-trainer.)
I didn't say memory-unsafe languages automatically lead to disaster. But all things being equal, the exact same system developed in a memory-safe language will likely have fewer bugs than the same system developed in a memory-unsafe language.
Thanks for reading.
I use this fantastic article of yours as "a quick guide to software quality" in my teachings as a IT trainer with Volkswagen (translate.google.com/translate?hl=...).
Thank you for sharing!
Great article, it helps put into words what many developers, manager, and clients experience on a software project. Some developers know that higher-quality code saves them a headache in the long run but it is hard to convince the other developers, management, and clients that investing in higher quality will lead to less rework and faster delivery. I will have to check out the books and research from Steve McConnell and Capers Jones, thank you for the recommendations.
You're welcome.
I've always been confused as to why people think faster is cheaper in any domain where you have to live with the results and pay for the maintenance for years or decades.
After all, you would want a:
Maybe one the most valuable articles here. Thank you so much!
So I am developing this hybrid app. It is kinda like simple social network app. It has been 4 months and yet it is still not stable and this is frustrating for me. I started to realize that the problem is in the core of the app since a few weeks. I mean bad core design choices.
And the reason for that was the time pressure that i put on myself. It was so strict that i didn't spend much time on design, made lots of shortcuts, didn't research well etc. And now i ended up with this buggy app so that I still need to spend time trying to make it more stable(if the bugs that i will produce isn't more than bugs that i will fix and then i needed to cancel the project). But if i wouldn't put this time pressure on me and research and design well, i at least would probably finish it by now. Not even mentioning all the other cost. So as you said low quality software is more expensive than high quality one.
So every single point in this article is extremely valuable for anybody in this area. I learned this spending 4-5 months. Hope people who aren't aware of this learn it by just reading this article.
You're very welcome.
Your story is common. I did something similar when I first was learning to program. Almost everyone errs on the side of too little process in the beginning of their careers. Without extensive project management experience it is extremely difficult to strike the right balance between "process" and just getting it done.
This is a great piece, thanks!
Mistake #37: Sales selling unicorns in the absence of any engineer, architect, consultant or developer.
Yes, absolutely. I think McConnell put it under mistake #8: unrealistic expectations.
It is definitely a common problem.
Blaine. You have just summarized my last 30 years in this industry. Top man. Well done.
Thanks.
I frequently wish our industry was more mature and this stuff want such a problem. It shouldn't be such a struggle to do what the research has said is best for longer than I've been alive!