May 5, 2023
Great Teams Don’t Grow On Trees
June 19, 2014
Your company is getting ready to make a major investment in custom software that might take you to the next level. How exciting and nerve-racking at the same time! You stand to benefit in huge ways by this software. As long as you’ve done your homework and have a good team, you’ll probably accomplish what you set out to do. However, if you don’t avoid some typical “time sucks”, you’re killing your ROI!!
Let’s face it, programmers are not always the best communicators (no offense to my programmer friends reading this article, but c’mon… am I wrong?). Poor communication amongst developers leads to time spent on misunderstood requirements. Programmers are notorious for being very sure of themselves and might assume they understand something even when there are huge gaps. Agile or not, if developers don’t understand how everything works together, they can end up painting themselves into corners. Nice thing about programmers is they can always turn lemons into lemonade. But the bad news is that getting that lemonade took longer than it should have and it probably left behind technical debt (that will cost you more later).
You are the most informed expert when it comes to your business and the software you want to produce. You might have an extremely clear picture in your mind of what you want in the end, but have you been able to extract those thoughts and translate them for the development team to use? If your dev team isn’t Agile, you’re doomed. But even with iterative development and a quick feedback loop, your development team needs to have a clear window into your thoughts and desires. Requirements should be described in standard ways and each should carry some criteria for acceptance. This might seem like a no brainer, but you would be surprised how many people like you miss the mark on this one, causing the dev team to need several more course corrections than should be needed. Course corrections are good, but represent some time spent in misdirection. Progress costs money, no matter in the right or wrong direction.
Years of study and research has taught us that, on average 80% of project costs arise from fixing defects (bugs). In fact, a study by Cambridge University in 2003 found that 50% of developer time worldwide is spent finding and fixing bugs. Why is that? Well, for one thing, writing software is not easy, no matter how highly we programmers think of ourselves. Defects are natural and part of the process of creating software. But too many defects can derail a project and cause costs to soar. This is a sad reality that is born out of a lack of emphasis and training in proven defect prevention techniques and practices. If your dev team is cranking out code without attention to bug prevention techniques like TDD, then they’re cranking out buggy code. Even though it’s a lot more fun for you to pay for forward progress and sexy features, you’re probably going to be shelling out more for bug fixes later on.
You are probably already convinced that Agile is the way you want to go. Most people think of “Project Management” when they think about Agile. But Agile, by definition, is simply “the ability to respond to change quickly.” That doesn’t only apply to the management of people and projects. Now, it’s great if your team can respond to change quickly during the development process, but what about the code itself? What happens when there’s a change that needs to be made 6 months after release? As with defect-prevention, there are industry-proven software engineering techniques, processes and practices that help guide software developers to more flexible code… Code that is welcoming to change… Truly “agile” code. But, too many times, we find that the code, though it works, only wants to work in one specific way. Any change to such code is like trying to dig up a grave from the cival war! From there, it’s a fight to shove a square peg into a round hole. Software developers can make anything happen… They’re awesome at that. But when the code is so rigid that it makes maintenance and feature upgrades tedious and time consuming, it ends up costing you a lot more than it should.
The best time to test a feature is weeks after it was written, right? Wrong! So much of software development depends on good old fashioned “memory”. For a programmer to be able to fix a bug, she must remember how, why and where she did things. Most development teams have excellent QA testers who are experts in finding flaws in software that programmers never dream of. Then, QA notifies the development team of the flaw and programmers begin to scramble to fix the flaw. Ideally, this workflow would happen in a tight loop. To accomplish this, the QA team should work closely with the development team, giving quick feedback on new features… Minutes after they are created, not days, weeks or months. But too many development teams save testing for the end of the process. Weeks or even months pass before a flaw is reported. With every passing day, programmer memory fades. So, the longer it takes to receive feedback on a feature or change, the more time consuming it will be to modify or fix it. If your software is receiving delayed testing, you’re paying too much for quality!
Now, I don’t know if you are the owner of your company or a director of a department… But I DO know that, either way, you have a lot to lose or gain from the software project you’re preparing to start. Chances are, if you are organized and have a good team of developers, you’re going to be able to produce something that makes your company lots of money. BUT, are you going to be happy with the average return on investment, or do you really want to maximize on every penny spent?
It’s time to look for a development team that knows how to avoid these ROI killers. If you have your own development team, it’s time to get them trained! Consider these 5 ROI killers that I’ve mentioned and get ready to shine.
If you need a team of developers who are well-trained in avoiding these ROI killers, let us know!