No, I’m not going to talk about anything related to the S.O.L.I.D. development principles. In any case, I recommend that every programmer learn them in depth and, above all, put them into practice.
Over the past few months, I’ve had to read a lot of tender documentation, and I’ve also been involved in proposals for new projects in collaboration with other companies.
In those tenders, some of them for regional governments in my country, the lack of rigor in the specifications stands out. In fact, one of them explicitly stated that “the tasks to be carried out will be specified precisely once the project has been awarded to the bidder.” Another said that the bidder had to adapt to the most common working methodologies, mentioning CMMI, Métrica 3, and so on. Well…
At the same time, most of those projects involve evolving applications that are already running in government ministries or departments in those regions.
How can you estimate the effort required to evolve something without seeing its current state? Will the solution be a complete mess? Will it be the usual spaghetti project, or will it have been built thoughtfully, with continuous improvements, code cleanup, and so on?
The thought of coming across something like that scares me.
Those projects involved technologies that had already existed for fifteen years and are still very much in use, albeit in more recent versions.
Another project, unrelated to the previous ones, involved working at a very low level with certain types of devices using the DLMS protocol.
And for a change of pace, I’m working as an external collaborator for a wonderful national company, a leader in its sector, called Altafonte. They use a PHP-based system, a MemSQL database, and so on. I consider their developers heroes: they’ve managed to keep advancing the solution, the foundation, and the core of their business while it grows and continuously takes on a host of new requirements.
Thinking about all these projects, what could they have in common?
Technologically speaking, it may seem like nothing: they’re completely different. And yet, from a more holistic perspective (as people might say in other contexts), the success of all these very different projects depends only on principles that are common and long-established—and that aren’t exclusive to our software development industry.
What would become of all those projects without proper organization and planning?
Anything that is moderately complex and extends over time needs organization and planning, whether it’s writing a book, saving for the long term, or building a software project whose solution will last for years.
And that is a job in itself. I’ve seen it many times, I’m afraid: things are organized at the beginning, but then they gradually fall by the wayside.
Any effort to stay organized has to be ongoing, and you need to set aside time for it regularly; it’s another task to include among your activities.
Of course, a project can be completed without the best organization, but it will almost certainly take much more effort, and people will have endured higher levels of stress.
Could any of those projects be approached the same way without continuous improvement?
In any long-running project, especially when current work depends on what came before, we need an attitude of continuous improvement toward everything already done. Otherwise, things keep growing on top of shaky foundations until the whole structure eventually collapses.
We need to hold retrospectives from time to time; the lessons they offer are incredibly valuable for moving forward with confidence.
In software, do we improve every kind of asset?
People tend to think that refactoring techniques apply only to production code.
Not at all. Although refactoring is a term applied to code, the other project assets can and should be improved at the same pace. And we shouldn’t forget that the quality of the tests should match the quality of the production code.
As a project grows, its structure, design, documentation, and so on need to improve.
I’m talking about software projects that need to evolve over a very long period—years.
Everything, absolutely everything, contributes to a better final result.
And what about workflows?
I find that organizations do things in a particular way, which may or may not work well, but they lack the awareness to clearly define a workflow for every process the company needs to carry out. It’s enough to write down, in some form, how this or that should be done and agree on it with the people involved.
That way, over time, we can identify shortcomings, track them, and improve those same workflows.
We might be using technologies from ten years ago or more recent ones. We might design a new solution around cloud infrastructure from the start, build a new mobile app using the latest Android API, use environments such as Xamarin or PhoneGap, or upgrade a Node.js solution based on version 0.12.x to the next major step with version 5.x.x, and so on.
Still, I’m increasingly convinced that all these technologies, which evolve, come and go, are just pieces of a larger puzzle. If you apply these solid principles correctly to your work, you may use an almost obsolete technology or today’s trendiest stack, but you’ll have a much better chance of succeeding and adapting to new situations.