When I was young and deciding what career path would I take and when our teachers would ask what do we want to pursue, I’d always answer something along the lines of: “software engineer”. Twenty or so years ago I had much esteem for the trade. The principles of automating repetitive tasks, freeing someone from the day to day burden of repetitive chores and of course, of their salary, leaving them naked in the street, unable to feed their family, hunting for mice to survive seemed such a good investment of my time and skills.
Of course, I’m joking! Jesus! But the software industry is not and the reason that is happening is because pretty much any other industry, be it automotive, manufacturing, even sending satellites to space (and trust me, I know) is full of repetitive tasks that can be easily coded to perfection.
With of all this, along the “success”, quotes intended, of the industry so did techniques have spawn up to help us be more productive. Let’s take for example Agile. Whenever I hear “Agile” and “sprints” (what a name for a stress inducer) for which sadly I must use the jargon, I also hear the PO or scrum master or whatever they call it now put an invisible deadline at the end of the sprint, the “we must release” need that makes all developers work mindlessly to reach it. It probably would be OK if there were technical debt sprints dedicated to re-factoring the code (and letting the developers hack a little at it to try out new things) but most companies today are “feature factories” (a sweet and non-smelly sweat-shop).
Back in my days, when I so cautiously and attentively read “Agile Estimation & Planning” by Mike Cohn, a founder of the Scrum Alliance, the “Agile” principles were about … cadence and estimating output based on previous measurements of team capacity. That has nothing to do with productivity or improving it. If you have a velocity for example of 25 points and adding 2 developers you reach 35 say to yoursef: “I was lucky!”. What happened is pure luck. Productivity can be raised artificially so but it can also drop like a stone, depending on the team “gelling”. For the concept of “gelling” read Peopleware by Timothy Lister and Tom DeMarco.
The above article on the blog of Dropbox triggered in me the realization that there was once a time in my early career where I didn’t rush to implement anything of the bat. I took time, “smoked” a Coca-Cola (used the balcony to stare into the deep blue of the sky and drink Coke) and then after hours of thinking I would go back and POC the shit out of the idea, only to repeat the cycle in the later days.
My current position is that of a software architect. What I’m actually doing is reconstructing architecture and trying to bring it to the standard (of TOGAF) on some projects where that is lacking. In doing so I’m also trying to find providers and sponsors in the business that will help shape the product carefully managing the need, aspirations and expectations of all stakeholders.
Upon this first-hand experience I can observe the lack of structure in thought, in workflow, in standards of the implementations. While there is sufficient standard in programming languages and there are sufficient frameworks to contain the development flow to an general contract or idea, this is not the same for the architecture, neither for its documentation and most especially neither of its business requirements.
In one of my projects, using Angular for example, a project done no more than 3 years ago, already 6 dependencies are marked DEAD, meaning no longer maintained by the original author. That means on our part an investment of people and time to maintain what otherwise was free. The bad part in that? The software gets installed on a system for which the lifetime of the system is 25 years so it must work then as it will do now.
While I’m not the kind of guy that signs Agile manifestos, I’d like to propose we, as a software industry, introduce the SLOW manifesto, guided by these 4 simple principles from which the abbreviation was formed:
- Simple designs or architectures of systems that are easy to explain to junior members in under 5 minutes.
- The system doesn’t need to be complex and require a Ph. D. to understand, but rather each component should be simple enough to be handled by one member of the team (think micro-services);
- Long-lasting or long-term supported dependencies of the above simple designs assure us that we don’t introduce bugs unwittingly.
- A version supported for much more time, even if it’s open-source, non-commercial licensing will have more support forums, chats, posts answered than your 1.0.1-rc2 version which comes out every 2 weeks.
- Organically growing teams around the principles that guide the first iteration of the product (meaning the first version that starts producing ROI) should keep that team going strong for the next years.
- If it so happens that a team grows beyond the number of 5, maximum of 7 people which is waaaay to much anyway, there may be a flaw in the design of the software package, where one must revision the “Simple” principle above.
- Wait for working software, last but not least software that has been put to its pass, tested, built automatically with CI/CD pipelines, deployed to a repository, integration-tested and much more. The kind of software a PO can release to a customer with a +90% guaranteed that the one-click install works, the documentation got auto-generated and packaged with the build, so only he/she has to do is press the “Submit” button on that Outlook.
- Neither Rome was built in a day and it took 6 days for God-All-Mighty to build the world. So don’t expect your debt-embedded software teams just waking-up to a project to start delivering every 2 weeks when they have to fight the dragon emerges from the code.
I’m not saying Agile is stupid. I’m saying it is misunderstood. Agile wants to enlighten people about a “cadence” of work. Agile is good but uses the wrong jargon. I’d use “cadence” instead of “sprints”. I’d use “rendez-vous” instead of “daily” and there are more tearms I’d find a more suitable, non-stress inducing alias to use.
What I’m saying is that we need to focus more on the principles that make-up good reusable software so that in the middle to long-run we serve our customer better even if at the beginning he may not always agree.