Building software is easy. Building good software is hard. Building great software is performance art. Here is how you can up your game.

Think about software you have used in a corporate setting, whether built internally or purchased at significant cost from some vendor. How often would you say this software blew you away with ease of use, speed of execution, fitness to purpose and stability? My guess is you will be hard-pressed to think of a couple of examples – and of those, most would be built externally.

So why is building good software so hard? I started building tools for oil and gas companies while still in university in 1996, continued building solutions for a leading reinsurer in Bermuda for 14 years and then again for the past 9 years running Treefrog Consulting Ltd. In that time I’ve seen a lot of mistakes made, many of them my own. While there are numerous potential causes of failure, I believe the following four are most prevalent in the insurance industry today.

Dev Team Size
In some ways building software is like surgery. It is not always effective to throw more people at a task. Just like having 5 surgeons jostling each other around the patient is unproductive, so is having multiple architects and developers second guessing each other on a project. A smaller team can readily outperform a larger one if each member of that team is granted a broad, but well-defined area of responsibility. Individuals hold more of the “big picture” in their mind while developing, leading to better decisions and fewer bugs.

Keeping the development team small has an added benefit. It makes it abundantly clear to the business that with so few people working on the task, it is simply impossible to implement everything everyone wanted. This is actually a good thing! Many features requested are nice to have, not must have. Leaving them out creates a leaner product that is quicker to market, faster to change and requires fewer developers to maintain. It also forces the business to prioritize its needs, hopefully leaving just the important stuff on top.

Developers as Business Analysts
It will come as no surprise that developers like to write code. It’s their job after all. Frequently they will actively avoid trying to understand the business needs driving the project, instead focusing their full attention on the coding problem as described to them by an architect or business analyst. In their eyes, this allows them to hone their craft, dive deep into the tech and produce a better product. Unfortunately, the results don’t often agree.

Business analysts and system architects are still people, so they make mistakes. They can fail to grasp some key element of a business problem and guide the dev team down the wrong path. Their lack of understanding of the nuances of a particular requirement may delay the dev team implementation while subject matter experts are consulted. Small mistakes in understanding are sometimes easy to correct, other times it is a small detail that spends months hiding beneath the surface until its critical nature is revealed, at which point there is a long remediation period required.

A developer that takes time to understand the business requirement for themselves will typically produce a better product than someone focused entirely on the code. Benefits of deeper business understanding include the ability to reach decisions regarding functionality without SME consultation, less reliance on a single “business interpreter” to translate what an end user wants into technical speak and greater insight into the future of the product beyond what the specs have clearly articulated. The benefits are bi-directional. The developer becomes more valuable to the company because of their heightened understanding of the business need.

Repeatable Release/Test Process
Have you ever gone to use a new version of some software and nothing works the way it should? Little bugs are everywhere, new features don’t work as expected and some old features no longer work at all? Did the last release go smoothly but the current one fall flat on its face? These are both symptoms of a poor release/test process. The good news is that this is easy to fix – at the cost of permanently slowing the release cycle.

The size of the development team has a big impact on how regimented a release process should be. If you have a single internal developer servicing a business unit, you may be able to get away with a few tests of the new functionality and some smoke tests of the old by one or two users prior to release and be done with it. But the bigger your team grows, the more could have been overlooked during the development and the greater the need for a thorough, formal release process.

A good release process should combine such elements as continuous integration, unit and integration tests, formal QA testing, formal user acceptance testing, scripted releases and at least 3 environments consisting of development, QA and Production. A project manager should coordinate release cycles with business cycles to ensure production changes comes at the least critical time. Infrastructure personnel should back up all production infrastructure prior to a release and be ready to roll back at moment’s notice. The entire process should be well documented, and the steps executed in order and adhered to by all participants. If you do this right, your users won’t stress that the core systems they depend on will break post release.

Business Decides Priority
Just as the military should be an extension of civilian government, a software development team should be an extension of business leadership. The business should decide what the developers work on and in what order because without the business there would be no paychecks! The developers and the IT organization in general should fully support the business that employs them so it is remarkable to me how often this is not the case.

The best person to decide what systems a business needs is the person that knows what the business must accomplish to please its customers, what regulations it has to adhere to, what reporting requirements it must satisfy and where its greatest inefficiencies lay. Further, when multiple departments vie for limited software development resources, the arbiter of what actually gets worked on should be a representative of the business, not IT. Obviously IT will have an opinion and reasons why one step should come before another, but it should be expressed in an advisory capacity to the business, leaving the final decision to be made by the business.

A development team that is working on something unimportant is doing itself and its client injustice. It is a waste of limited resources and a permanent increase in the code maintenance burden for that software. It is making its client less competitive, less flexible and therefore more likely to disappear in a few years.

Doing the above four things well will help your business succeed in its software development goals. It will minimize waste, maximize efficiency and help keep your organization nimble and able to react quickly to changing market conditions. During my time with Treefrog Consulting we have seen these techniques work for clients and have implemented them ourselves when building Foundation, our reinsurance pricing and portfolio rollup platform recognized with Bermuda’s Technology Innovation award.

To learn more, visit www.treefrogconsulting.com or email info@treefrogconsulting.com.