You have a great idea. And you want to make it happen fast! All that’s in the way is a little bit of easy code, and it’s done. But then you see the result and you remember there’s something you want to change. And so, the programmer changes it. And this happens a few more times, but now you notice that the first pieces of the software aren’t working anymore! How did this happen?

Goal: Stakeholders want their system to be built accurately the first time.

Problem: Stakeholders don’t have complete information about their project ahead of time.

If it were possible to describe fully and completely how a software program should work, and then let the programmers create it to that spec, that would be ideal. In theory that works. In the real world, there are many things that the stakeholders haven’t thought through no matter how detailed the design documentation.

I use a feedback loop that helps build software. Build a small piece, client requests changes, upgrade that piece, and so on. Then build the next piece. The shorter the cycle time, the easier it is for the stakeholder can see positive progress and influence the direction of the software. It saves time in the long run when you compare it to the programmers hiding in a black box for six months and delivering a “finished” product.

If you’re a stakeholder, you can request weekly or every other weekly meetings to show progress. If you’re a programmer, you can request the same thing – even if the stakeholder doesn’t know they need it. It’s much easier to throw away or change one week’s worth of work rather than six months.

Goal: Stakeholders want future changes to their system to be easy.

Problem: Stakeholders don’t have complete information about where their project will need to evolve in the future.

You may have a great idea for your piece of software right now, but in 5 years, the market will have changed, and you’ll need to make changes to your business rules and how they play out in the software. I hear people complain about how their development company takes two weeks to make such a minor change. This is caused by poor software architecture. You may have built a great system “quickly” initially, but when it comes to changes in the program, they are fiercely difficult to make. Luckily, there are better ways to build software.

As a stakeholder, you can help programmers by saying “this rule might change in the future”. For example, you might say, “We might find another credit card processor we want to use in the future. Make sure that’s easy to change.”

As a programmer, to make systems easier to change you can use SOLID design principles at the architecture level, or Orthogonal architecture, or a similar methodology to break the system into components that are “plugins” and easy to swap out. Doing this has let me change credit card processors, highly customized accounting systems, even databases with much less effort.

Goal: Stakeholders want their system to run reliably for years to come

Problem: Programmers feel pressure to build the system as quickly as possible, and this leads to shortcuts.

With any business venture, you’ve got to balance quality, speed, and price. The same can be said for software. So how do you build a system quickly that will reliably work for years to come? Simple term, complex answer: Automated Testing. As a stakeholder, you can help programmers by allowing extra time to build automated tests as the application is being built. As a programmer, you can stick your neck out and tell the stakeholder that while automated testing will cost more in the short term, it’ll save countless dollars when their business idea is making millions.

Here’s a story from early in my career that cemented the need for automated testing. We spent one day building a simple application. We had written requirements. It took eight hours, and the application wasn’t working in all the cases. Adding a new feature just always seemed to break the last feature. It was par for the course. “This is just how software is developed. We work out the bugs the next day, right?” The next day, we started over from scratch, this time building automated tests alongside the application. And we finished the project in 6.5 hours. And it worked in every case.

Wait, did I just say that testing made the application build quicker? And work more reliably? Yep. So as a programmer you might think you’re saving time by not testing. And as a stakeholder you might think you’re saving money if you don’t have automated testing. But both of those are lies! It’s faster and more reliable to test your application.

Can you get an application that is reliable, that you can change easily and also the “thing you actually want”? Yes! It’s all possible, and it takes good communication on both sides, and a little bit of professional software development on the programmer’s side.