Building software is hard, but nothing worth having comes easy in life. Let’s discuss this.
The journey of software development is full of pitfalls in all the various stages of the life cycle, starting with pitfalls during planning ranging through to the maintenance of the software.
Luckily, with a can-do attitude and the right kind of people and experience on your side, these can easily be avoided. I aim to touch on merely a few ways in which some of these pitfalls can be avoided.
1. Analysis is key
Analysis, the detailed examination of something complex to separate the whole into its parts, is arguably the most important step to set up any project for success. By having a detailed understanding of the problem set and the environment it occupies, the best choices can be made at the outset.
By asking the right questions and fully digesting the problem set, elements may arise that have not been thought of before as the opportunity or space has not been available up to that point. It may even be a case of being so familiar with that element of the problem, that it is no longer a consideration and thus did not come to light in the original problem statement. When these elements come to light at the outset, the impact on the project is less costly as it can be catered for upfront, rather than attempting to cater for it on the road.
The analysis is fundamental in establishing a proper foundation for the project, and we all know what happened to the man who built his house on the sand.
2. Visualization aids success
Software is written for people, and people are visual creatures. Research has shown that humans process visuals significantly faster than text and that the majority of the information absorbed by the brain is visual.
It is for this reason that wireframes are a great place to start.
Having a visual reference point for the software that is about to be built aids the client and development team to collaborate more efficiently around the requirements, changes, limitations, and opportunities.
It provides a common language between a technical and non-technical audience. When misalignments in requirements are highlighted early on, it reduces the impact of change that needs to be brought on. It also certainly spares everyone the disappointment of this realization after development has started.
A picture may be worth a thousand words, but in custom software development, wireframes are worth so much more.
3. Tech stack matters
Building software is all fun and games until it goes live, and people start using it.
While it remains true that the chosen tech stack needs to be realistic and capable of solving the problem while still sticking to the budget, it is also important to consider other factors such as where it will run, who will support it, and who the average user will be.
When new software is going into an existing environment, the existing infrastructure should bear weight on the technology choice. If the environment is new and no existing infrastructure needs to be considered, the capabilities of those who will support it should be. Minimum browser requirements, device specifications, and other considerations can more easily be informed by looking at who the end user is, and thus should be considered when choosing. Speaking of end users, the anticipated number of active users is important, as this will be a good indicator of the anticipated load.
Something that is often overlooked until much later in the development lifecycle, is the volume of data that needs to flow, be stored, or be processed. Interrogating the anticipated lifespan of the project, together with the anticipated number of overall users, can indicate the volume the system is expected to handle.
Choosing the tech stack carefully will ensure that not only the problem is solved, but that the solution fits the environment it goes into, operates efficiently, and can be supported throughout its lifespan.
4. Know your audience
Tied to the point around keeping the end user in mind, take a moment to visualize a trained call center agent on a Monday morning busy on a call supporting an upset customer with a query or complaint, attempting to locate the customer record on the company’s system. Got the mental image? Great, lock it in.
Next, visualize a single parent on a Monday morning attempting to register online for some service that they heard about over the weekend, while the kids eat their breakfast and complain about having to go to school.
Now think about how these two individuals interact with their respective software, how their needs are both alike and different in various aspects, and how much training and knowledge came before their interaction with the respective software.
Ultimately, they are two fundamentally different end users. The call center agent underwent training on the system some time before them supporting customer queries, whereas the single parent only has their knowledge from prior experiences with similar software.
A call center agent may feel every millisecond of processing time of the software, the average user may not even notice it. While the call center agent is trained on all the ins and outs of the software, the average user relies on the user interface to guide them to the appropriate action. A call center agent may not fully appreciate the efforts of an artistically designed user interface, and the average user may not be drawn into a bare-bones version of a user interface.
It is for this reason that you need to know your audience. Knowing who the targeted end user is can help ensure that the software is developed for that user.
5. Ignore the Siren
A common lure to attempting to save labor and time costs as it relates to custom software development is to opt for an out-of-the-box (OOTB) software solution with the thinking that the features that are not an exact fit or not available, can simply be customized.
With this, I am not referring to the customization of the elements and features that were designed and intended to be customized by the OOTB provider. In fact, there are many successful cases available online where OOTB software solutions were used when they fitted the business needs, and with the customization of features being done as intended by the OOTB provider.
The Siren I am referring to here is the veering of the intended purpose of the features provided by the OOTB solution, by customizing or adding features to fit specific other needs when the customization or addition of these features is not supported by the OOTB software.
While I understand why this may look tempting, especially when the budget is tight, I would argue that this route will ultimately cost more.
The development team is sure to run into unforeseen and unknown issues, thus causing delays in the timeline. Some issues may be of such nature that further costs have to be incurred to overcome them. A situation may arise where some needed features are to be excluded from the scope as it simply cannot be done, thus compromising on the solution, or a complete pivot must occur whereby the development up to that point is written off and a different solution is to be chosen.
Further to this, the client will experience not only issues with the maintainability of the software but also incur continuous development costs for the lifespan of the solution. The reason for this is that when the OOTB provider pushes updates for the OOTB solution, and because custom development was done on it, further developer involvement will be needed to keep retrofitting the custom parts into the existing and potentially now changed structures.
Moral of the story? Be the pirate, not the sailor that is lured to their doom by the Siren.
Parting thought
Custom software development is often accompanied by a lot of unknowns and uncharted territories. Some view this as a downfall, a negative aspect if you will. I believe the contrary; this is what makes bespoke software development so exciting and rewarding.
If you think about it, almost all the technology, software, and inventions that we encounter today were once thought of as impossible. Therefore, do not shy away in the face of the unknown or unfamiliar.
Whether you are a jack of all trades, a junior developer with big ambitions, a manager with big shoes to fill, or a senior executive looking to leave a legacy – we all had to learn to crawl before we were able to walk.
The point that I am getting at is that custom software development, despite all the pitfalls (avoided or not), can be a huge success. You just have to be brave and take the leap.
And always remember, at the end of the day when the dust of the development lifecycle settles, you want your software to fit the business needs, not retrofit the business needs to fit your software. Let’s face it, that is why you went custom in the first place.
