A lack of clarity and ineffective communication are among the common reasons for software development failures in local organisations.
This is according to Joe van der Walt, Founding Director at Kohde, who says surprisingly simple changes can make the difference between software that delivers value and software that doesn’t.
He notes that software systems are, by definition, challenging to deliver. They are categorised as complex due to the amount of uncertainty involved along with their ultimate goal – to deliver value.
“The problem is that your team and your customer will only learn whether the solution is valuable once the software has been built,” he says.
Nobody cares about your architecture
Van der Walt says a system with a good architectural base will be able to serve thousands of clients, be defect free and deliver on the promise of value to users and stakeholders.
“The problem with good architecture is that it is not easily developed. It is an intricate balancing act between what is cost-effective and what will reasonably work. Software architecture influences cost, time to market, scalability, maintainability and quality,” he says.
“We have seen customers achieving initial business success with poorly developed architecture by simply getting to market quickly. However, these successes are usually short lived, due mainly to the fact that the architecture has to be rewritten, causing delays in future feature delivery and often having tremendous cost implications.
“The main challenge is that businesspeople do not care about your software architecture. It is a lot like the air we breathe: no one thinks about it until you can't breathe. What they do care about is when business initiatives are not being met or when it takes a lot of money to make simple changes,” he says.
Van der Walt’s advice is to decide on a set of non-negotiable principles when designing software, no matter what the requirements are.
Some non-negotiable principles should be:
- Write code in a way that is simple to understand and easy to change without the system breaking.
- Making sure that software works, writing automated unit tests. This practice seems simple, but increases the quality of your architecture in myriad ways.
- Monitoring software in production. Software should be designed to accommodate centralised, user-friendly monitoring and health checks.
Requirements change
Van der Walt recalls realising early in Kohde’s software development journey nearly a decade ago that the team practically never built exactly what clients initially requested.
“I used to get extremely frustrated by this,” he admits.
“Thinking about it now, it seems silly to have thought that a customer would be able to fully understand and map out a complete software solution to be dictated to us. The reason we are employed is not simply because we can translate words into code, but to help our customers understand what it is that they need,” he explains.
Kohde’s advice is to accept that requirements will change as you go along. “I’d go so far as to say that requirements must change. The change is where we are capturing the value of the system,” he says.
Get on the same page
To deliver a successful software project, it is crucial for business, IT and developers to bridge any gaps in understanding, and communicate in a way that everyone understands, Van der Walt says.
“One of our clients told me recently that they had to Google the term ‘API’ after one of our meetings. They were embarrassed that they didn't know the meaning of a word so commonly used within the technology environment. It got me thinking. IT has so many terms that could be confusing,” says Van der Walt.
Kohde has found that visual tools for sharing information and ideas outweigh traditional documents. A simple wireframe prototype has saved their customers a lot of money in terms of rework and misunderstanding.
“Investing in visual ways to share ideas and to get everyone on the same page as to what is going to be delivered can be helpful, and should continue throughout the development process,” he says.
Software should work
Building software that just works may sound simple, but while many software systems may appear to be functioning well, underneath, they are often plagued by technical errors that go unaddressed.
When Van der Walt encounters a system like this, he asks the engineers why issues haven’t been fixed. The answer is often something along the lines of: "The client doesn’t want to pay for it."
Van der Walt says: “The reality is that the client is already paying. Broken software doesn’t deliver value – it only undermines trust in the quality of the work being delivered. My advice is to prioritise testing and monitoring software, especially when it's live, to catch and fix hidden defects. Address these issues before developing new features. Your clients will appreciate it.”
Maintain momentum
Van der Walt says many software initiatives fail because they fail to build good momentum and deliver working software into people’s hands as soon as is reasonably possible.
“This can make it seem as though the software will never actually go live. It breaks confidence in the solution and ultimately forces the client to look for alternative solutions,” he says.
“One of the biggest momentum killers is manually managing IT system change. These include change approval boards, change ticketing systems and other red tape that stops frequent incremental changes.”
He notes that the IT tooling to manage system changes has improved significantly in recent years, and the merging of developers and infrastructure specialists means that most of the work required to manage these system changes responsibly can be automated, with support for rolling back or rolling systems forward, while keeping full audit logs of these changes.
“The ultimate goal is to be able to make changes, almost immediately, while using systems that act as guard rails to prevent major outages,” he says.
Kohde's recommendation is to automate these processes as much as possible. Developers should be able to provision new infrastructure and deploy systems into production without having to attend change meetings or submit extensive deployment and rollback plans.
These processes should have automated validation checks that prevent the deployment of defective code or infrastructure. Automated production monitoring can limit outages, with early notification and patching.
Van der Walt says: “Another momentum killer is queues. A queue is when a team gets blocked by waiting on something. In an attempt to optimise costs, many businesses implement a structure called shared services. In this model, a single team is responsible for a specific technical or business function.”
Kohde's advice is to actively work on removing queues, and to use technology to remove these as much as possible, and to let teams get on with work.
Communication is crucial
Van der Walt believes that most problems can be solved with good communication – both internally and externally. “Even if things seem to be going well, it is important to keep a consistent communication cadence. Communicating bad news is especially difficult, but the most important,” he says.
Kohde’s advice is to keep communicating, even if it seems unnecessary or too much. Communication creates enormous amounts of trust. It is important to take our clients with us on our journey to produce solutions.
Conclusion
Van der Walt says building software that truly delivers value is as much an art as it is a science.
“Over the past nine years, Kohde has discovered that successful software projects are built on a foundation of adaptability, clear communication and a commitment to constant improvement,” he says.
“Architecture, while often overlooked, becomes essential as a system scales; requirements evolve as clients learn alongside Kohde; and momentum and clarity are vital to keeping projects on course.
"Above all, keeping open channels of communication and fostering an environment where continuous learning is encouraged has helped Kohde turn challenges into valuable insights.”
Share