I started development in 1990, working on a Unix OS written in C. Our 'office' back then was called a lab, we revered old-timers who often only worked at night, and software patches were emailed as file diffs.
Google, Linux, Amazon, cookies, wifi, laptops, etc, all yet to come. Peak excitement was DNS becoming popular and usable, enabling something called the World Wide Web.
In the early days I worked on a product called SCAFS, which was a hardware cache between the OS and hard drives. It cached SQL queries, delivering above 20x performance. Very smart back in the days of SCSI ribbons.
We were a diverse small team of hardware, systems, marketing, sales. There were bugs and features, and a general roadmap. We talked a lot with customers, consulting or at trade shows.
Our product was autonomous, yet integrated with the OS dev team, high-performance server team, and external database companies. I think we shipped hardware/software rev's every three months, with bug fixes going out quicker (on magnetic tapes!).
Looking back, it feels like I had an informal apprenticeship. I met so many different types of people and different ways of working on things. The people and culture taught me to be responsible, do what I commit to, and the importance of effective communication.
Today I can easily recognise that we were a fast moving team that was able to work asynchronously.
The very definition of agile.
But we had no formal culture-framework imposed upon us. Rather than be infantilised and micro-managed, we were expected to be adults. Ideas and opinions travelled freely, whereas now they are siloed off (irony!) by dogmatic Kafka-esque processes.
I despair at what business has done to the process of technology development. Agile is the business version of engineering process, sold to developers as self-empowerment. It is a cult that feeds on narcissism.
More agile, less Agile.
These days, while I work solo on a web app, I think a lot about coding less. 11,000 lines-of-code probably has fewer bugs than 22,000? One risk of solo development is that your project is suffocated by time spent fixing bugs. There's a business motive here.
Writing less code is of course quicker to do, but it requires spending more time on the engineering process. Better engineering means less code, means more engineering time, etc.
I try to deploy weekly. My commitment to my future self is that I must include 'how to troubleshoot this feature' in the docs. My template is below.
Monday to Thursday I work up my plan while walking or doing other things. Great ideas seem to surface when you least think about them. Long walks in interesting places seem to be the best place to rationalise thoughts.
Friday to Sunday is when I code. When there are no design decisions left to make, coding is really easy and quick.
This goes against Agile, against what many have only known. You can try it, and see what happens. Try a challenge from AdventOfCode, spend a couple of days working up a plan first. Did you write a cleaner solution? Now extrapolate.
This 80% thinking and 20% coding may seem counter-intuitive at first. But it results in faster development, lower operational costs, and higher motivation. It just changes things, when you realise good software development is not really about writing code.
Maybe not today. Maybe not tomorrow, but soon and for the rest of your life.
This way of planning is not really anything new. It's centred on trying to communicate change more effectively. In my case, currently, I'm communicating with my future self via a walkthrough.
My assumption is always that no-one spends time doing a literal code review any more. So if someone reviews my walkthrough, and I commit to writing code that reflects it, that's a proxy for a meaningful code review.
However we do software post-Agile, businesses that ditch micro-management and embrace autonomous asynchronous work will make better software.
Template
I created this template in the Things3 app on Mac and iOS. I wanted simple task management, that I could read and edit on the move. The ability to show tasks in a Home Screen widget is great for keeping scope limited.
#### Trigger
What happened to make this worth doing.
#### Purpose
What functionality MUST be delivered.
#### Strategy
- High level decisions I will take to do this.
#### Thoughts
- Any context to decision making, peripheral things, knock-on's, etc.
#### Walkthrough
- [ ] First thing to do
A task description. Adding pseudo code lets me evolve function/var names and types as I build up the walkthrough tasks.
func loadData(id int64) account.Data {
if !dataExists(id) {
fetchData(id)
}
return getData(id)
}
- [ ] Second thing to do
Of course I'm generalising about Agile. It's not all bad (hey future employers!). But we do lose something when business runs software development.
Top comments (2)
Indeed, the problem of modern development "process" is that there is too little thought and too much iteration. You end up iterating incomplete crap on top of crap because it has to be broken down to be delivered in fixed time silos called sprints, in whatever partial and hence rather useless form it may exist in, just so that managers can see and measure people "working". If you're not seen rowing the ores, even if you're doing so in the wrong direction, your presumed to be idle.
It feel like it's gone in the same bin as '360 performance reviews', etc. Things that have a grain of common sense, but it's now more about being seen to follow the process rather than benefiting from the process.
And you're right, the ones that seem to do well are happy to be seen to do the process (irrespective of actual development competence).