Some thoughts about Software
I wanted to share with you some thoughts about software (and web) development I have. A kind of brainstorming.
When I build software, I apply some basic rules to set the bar: encapsulation, abstraction, code reviews, tests… but I never predict the future.
I avoid over engineering; for example, I don’t create a DLL to encapsulate my logic if I don’t know for sure if someone will consume it.
I do trade-offs and choices in the present moment (and I try to be pessimistic).
I don’t use “to-do” in code, I don’t prepare my designs to support a hypothetic changes.
I prefer to refactor than invest too much. Why?
First of all, because there are only two kinds of software: the failure and the legacy horrors.
There is a high possibility that your software will never be published, and if it is the case, it would be considerate as a big shit by the next developer…or yourself.
I see software like a city. We build a city with the budgets and requirements of today. If many bugs/troubles come up, we don’t destruct the city to build another one. We do improvements by steps.
That’s why I don’t recommend replacing a software by another one created from scratch. All companies who tried it had a failure or a money drop or both. They keep updating the software A and in the same time are building software B. As software A evolves in one direction with bug fixes, software B takes a while to ship and go to another direction. As soon as you ship software B, users want to come back to software A because it doesn’t respond to recruitments and/or doesn’t have the same experience (black box effect) and bugs/usability are/is a disaster.
With time, we encapsulate, isolate, abstract and we remove the code that needs to disappear.
The software is like a living organism that evolves with time.
That’s why I need to be able to change it fast, as requirements and experiences change. I need to experiment, avoid the black box effect. Agile methodologies are mandatory to accomplish this.
A process that serves engineers and not the inverse.
I try to avoid comments, documentations. The code expresses itself.
I want my engineers to be agile, to be a PM, an architect, a tester, a DevOps of their features at the same time.