Isn’t it enough if the software works well?
Definitely not! I’ll explain why you should want to know which programming techniques, programming language and tools we use, and what we do to optimally structure the code and document everything.
I understand your initial reaction might be:
“Spare me all the technical details, please!”
But I can guarantee that if that’s the way you view things, it’ll cost you a lot of money. Continue reading to learn why.
The size of the project
The size of the project definitely plays an important role in the developmental stage. In small, straightforward projects, any additional costs are manageable if, for example, it turns out certain things have to be rebuilt. Whereas this is often not the case for bigger projects: we’ve seen cases where the project had already taken up a few hundred hours and then had to be scrapped and redone due to mistakes made in the early stages.
Programming language
There are lots of different programming languages. Our advice? Stay away from all the ‘exotic’ (barely used) languages, because if your programmers happen to be unable to continue on, finding a replacement will be difficult. And who guarantees that an exotic programming language even has a future? That it will be continually improved, and secured?
Moreover, all programming languages have pros and cons and not every language is right for every project: let someone you can trust, who has experience and whose main priority is to help you, advise you.
Topulus has partnered up with PHP (for smaller projects) and .NET (for medium sized and larger projects).
Structuring and documenting
Programmers are expected to apply optimal structure to their programming code and to document their process well.
The manner in which programmers apply structure is of great influence on the quality of the eventual code and with that the maintainability and extensibility in the future. Perhaps you wouldn’t expect this, but programmers are constantly tempted to start working sloppily, by quickly editing something or forgetting to document the process. This saves time, after all – and doesn’t affect the functionality of the project works. But if the code turns out to be filled with lots of little small changes, it can cause all sorts of trouble.
That’s why there are tools and techniques that more or less force the programmer to work in a structured manner. More about this later.
But why is the structure in the code so important? If the code is unstructured, of which the informal name is a ‘spaghetti code’, working on it in the future will get very complicated, and sometimes even impossible. Say you want to repair a bug in the software, various unexpected and illogical dependencies might reveal themselves and negatively affect your logical edits elsewhere in the code. In other words: several things will go wrong, in several places. Then you’ll have to figure out how to fix it, by making edits with potential new unexpected results.
One rule and indicator of programming well is that should a second programmer take a look at your code, they are able to seamlessly continue where you left off. That guarantees that your product has a future.
Maintainability
Why would you want to continue with your code in the future?
Well, that’s necessary to ensure security, for example, but also to fix mistakes or build in extra functionality.
Building software is a continuous process, where you regularly need to maintain and change the code.
And that’s where structuring comes in, because if everything is structured well, maintenance will be a lot easier and programmers will be able to work as efficiently as possible.
Example: Recently we’ve taken over management of software, which several programmers had worked on over the years. The software worked fine; all users were happy with it. But when we made some adjustments, we discovered that certain elements that were normally defined in one logical place in the code, sometimes appeared in 6 or 7 different places. Although our adjustments might’ve slightly improved a few things, it also had unwanted and unexpected consequences in many other places. And we had to check and repair all of those consequences. But every repair also presented this exact same problem, so it was a hopeless task. At the end of the day, everything can be solved, but in situations like this it costs an incredible amount of time. And the code has no ‘future’, because if you really want to make big changes, the cheapest solution is to start over. And in projects that have already taken several hundred hours, you are talking about serious divestments. That is exactly what we decided for this project: we have completely restarted and have thrown away a 500-hour project. And that wouldn’t have been necessary if this project had been set up right from the start.
In the interest of
We’re very aware of the risks we’ve described in this blog. When it comes to the decisions we make and our transparency on our website concerning those decisions, we believe we work according to one set interest: the interest of the customer.