I’ve been mulling over a draft post I’ve had for a few months in which I was going to systematically and convincingly eviscerate the Scaled Agile Framework, or SAFe. I had plenty of arguments in bullet point form and the supporting material mostly thought out already. I even had a witty title in place, “UnSAFe at any Scale”, unapologetically stealing from Ralph Nader.
But I haven’t been able to write that post.
It’s not that I’ve had some sort of epiphany and now see the value in SAFe - quite the opposite. The recent move to put all SAFe documentation behind a paywall simply reinforces my perceptions of the motivations of the people behind it.
This feeling - this block - has been more about being tired of complaining about all that’s wrong around us, both inside the software development world and outside.
Instead, I’ve decided to write about something positive. I want to create a buffer against the constant stream of bad news we receive.
I want to write about what I’ve seen “work” in my software development career versus complaining about what doesn’t work.
I’ve been building software systems professionally since the late 1980s, though my first program to be used by someone other than me was written in 1982 while I was in high school. That program was for my basketball coach for tracking team and player statistics. I wrote it in Applesoft BASIC on an Apple ][ Plus and had to learn a few things on the fly, such as disk I/O, because we hadn’t covered that yet in Computer Science class!
Since I didn’t know any better at the time, I would build a bit of the program, show it to the coach and let him use it, get his feedback and take that back to building more. I was doing this on my own time, so it amounted to several hours per week and 1 or maybe two of those demos. I kept using that approach until there wasn’t anything left to add or change.
I’m not sure how long he used that program after I graduated, but I learned a ton about delivering software from that experience, even if I didn’t realize it at the time.
There was one small issue - when I went off to university to learn how it’s really done, I was taught that my approach was all wrong!
I learned that I should have been eliciting requirements from the coach, analyzing them, producing a system design & functional design, getting those approved, writing the code with extensive documentation, creating & executing a comprehensive test plan and completing all the system documentation before finally giving him the program. I felt like an amateur, which, to be fair, I was at that point.
At the same time this was happening, I had taken an Introduction to Business course as an elective. It was also the primary course for students in the Business Administration program, so it was anything but fluff. We initially studied stocks & bonds and their markets before moving on to the theory of management. That segment of the course started with, I believe, two lectures on the origins of management, specifically Frederick Winslow Taylor’s Scientific Management. As of this writing in December 2024, the second of those lectures ended just about 40 years and 2 months ago and yet I remember it clearly. The professor finished speaking, closing the binder with her lecture notes with some flourish, looked over her glasses at us in the lecture hall and said, “Now forget all of that because it doesn’t work!”
After university, and even during while I was a student working summers at a local telecom company, when I wrote software that others had to use I kept reverting to my original approach of doing a bit, getting feedback, adjusting based on the feedback, rinsing and repeating until there was no more to add or change. I still felt some guilt, though, about not being “professional”.
I did, however, develop a reputation for getting, um, “stuff” done and went on to a very successful run as a contract software developer.
Coming up in the next post, I’ll discuss how my guilt over feeling unprofessional would come to a head.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.