We've all heard the analogies. Someone's trying to explain some aspect of software development and they inevitably compare the process to... build...
For further actions, you may consider blocking this person and/or reporting abuse
I was a bit confounded when you said you were going to make this comparison. Having read it now, I agree with the majority of your points, and think this is an apt comparison. The one major difference is urgency; medicine often has incredible urgency where programming can take a step back and think when needed.
To provide a concrete example towards something you said. We definitely don't know what we're getting ourselves into most of the time, and being flexible and reactive is a huge part of it. Even without medical knowledge, I'm sure the first thing you'd think for a patient coming into the ER with his "arm torn off" is a tourniquet. You'd be correct. So, I had everything ready ahead of time expecting that, with no complications, since that's very urgent. EMS neglected to mention this was a farming accident and the man didn't just have his arm torn off. He also had cow manure everywhere, including in the wound. The entire "playbook" went out the window, because now we have to carefully balance cleaning out the wound so he doesn't get sepsis, with stopping the bleeding so he doesn't bleed out. Curveballs, not necessarily this severe, are the norm, and it's expected any medical worker can think on their feet in response to new data. The "spec" is always the same, but what we think the "spec" is constantly changes.
A more technical example, is I applied this kind of thinking to some software I develop, since, it's what I know. I had some rough design requirements; a problem I was trying to solve. But that was it. How long would it take? Idk. How would it be implemented? Idk. It wasn't TDD because I didn't have a concrete spec; I couldn't. I just dove in, keeping the hard requirements in mind. What started as an uninspiring and "misguided" project many tried to talk me out of, turned into a major contender among parsing frameworks. I made constant little UX and perf tests, and refined everything until I eventually had a spec; the spec, or "diagnosis" was a late product. The design I have barely resembles what I thought it would be. No amount of design docs or meetings could have gotten me there. But I wound up with what seems to be the worlds first allocationless parsing framework, reliably in the top 3, and usually 1st for every performance benchmark I've seen (near 100 cases now), and with far less required knowledge than parser combinators need for anything non-trivial.
Looking at it both ways, I completely agree. I liken what's being done now, to the philosophers of old thinking if they thought long and well enough, they could know, upfront, how many teeth were in a sheeps mouth. You can't. And that you can't spawned sciences hypothesis-test-infer approach. This is Computer Science not Computer Philosophy right?
Excellent points! And I love that you bring up the term Computer Science. I always thought that term was a bit "lofty" for what we do (unless you're, like, developing the next generation of quantum computers). But now I think I should embrace it more. Because science isn't about having all the answers. It's about following a rigorous process in an attempt to find those answers.
Exactly. I had a hypothesis on how I could design a good parsing framework that solved the problems I laid out. I set up falsifiable and reproducible experiments (both benchmarks and UX tests) with a null hypothesis. The times I was right, I went forward with that approach. The times I was wrong, I rewrote that component with a new hypothesis.
Ironically, science tends to be more about finding all the wrong answers. We know a lot more about how things don't work than do. Less glamorous way to put it though.
The obvious caveat here, is anyone reading this that writes software for life support machines, or anyone on the Boeing team.
For those people, software bugs are somewhat more important than the rest of us.
Absolutely. My original programming language was Ada, so you can guess the kind of stuff I was doing. When there's a physical product that's being controlled by the software, the whole process is drastically different. You know exactly what you need to do.
I have to admit... nail hit on the head.
A previous manager used to refer to me as "SpecOps Dev" and when I queried him on it, his response was "I can drop you in on a Production bug, no background, no tools, no prior knowledge of the system you're looking at, no-one to help you, and you always get the job done while giving someone else the credit. You have the strange ability to be able to just do absolutely anything I throw at you. Don't worry, it hasn't gone unseen."
I've also taken a complete novice (could barely use MS Office!) and within 6 weeks, he had written a complete application to have a RaspberryPi actuate a series of physical switches. I started him off by teaching how to think about the problem in UML.
It was that experience with the novice that changed what I tell people at social gatherings in response to "So, what do you do?"... my response now is something along the lines of "We know more about the universe than we do the seas... I basically head off into uncharted water with all the care & attention that airline pilots have... only I do it for a software company."
I'm spread across being a Lead Dev / Architect / Change Manager / PM / whatever other hat I need to wear, and today, I'm covering our Helpdesk Manager's day off while writing code... there's no way you could even start to explain all that to someone that doesn't already live & breathe commercial software development. So I stopped trying.
Thank you - and well said!
👍 Man, you should write a book
Yeah... it'd be shorter. 😁
Great article!
I totally agree that developers should not be isolated from the decision process.
For me, that is the biggest takeaway from the whole Agile movement.
Is not just about splitting your work into sprints and have a daily standup is about having access to ask questions, clarify specs, or throw them out the window if they no longer work.
That said there are certain types of programming jobs that work more like a factory assembly line... and that is fine. To use your metaphor about Medical care, not all programmers should be brilliant neurosurgeons, we also need nurses and general doctors and whatnot.
The funny thing about the construction metaphor is a lot of people use it because they think that everyone understands construction, but actually, most people don't.
Most people have no idea how much effort is involved in building a house, what are the steps you need to take, and how much is going to cost them.
Same as in Software there is not a single big and complex construction project that does not stumble on some unforeseen problem or complication that stretch its budget and deadline.
Thank you for the great article, it made me think about a lot of things.
Great feedback! And yes, it's absolutely true that most people don't really understand construction (myself included). If they did, they'd probably stop using that analogy.
I do believe that the process of designing software can be very similar to being an architect. But in the dev-is-construction metaphor we usually fall back on the idea that the actual construction phase is static - as though all the planning's already been done, and now those guys with the big machines and the power tools just need to "make it happen".
Well, I know I'm quite late to the party, but I recently stumbled upon one of your pieces, and I think they are very insightful.
I can resemble many of your ideas - I see myself more a craftsman than an architect or a doctor.
Why? Because craftsmen plan and build things. Like a carpenter plans and builds a new table or a cupboard, he/she can also repair an old chair - using his craft, tools and sometimes replacement parts.
And everything you find another type of chair, table or cupboard - sometimes similar, sometimes not.
And even if the carpenter builds a new house after a plan an architect did - the wood is always unique, the grounds are unique and the building teams is unique - so you will never build two identical houses - each and every house is a unique piece of work, like every new software is.
Yep - totally agree! Maybe I fall upon the medicine analogy because I'm often called on to diagnose and treat issues that exist in current apps. But I don't disagree with you at all. When you're building a new app from scratch, many people use the analogy of building a house. But I don't like that analogy. Because most houses nowadays are built from pre-existing architectural plans - basically, the building part of it is like putting together a kit. But the reality is that it's never as much like a "kit" as the client believes. There's always a lot more craftsmanship that goes into it. So, yeah... I totally agree with what you're saying.
Great one
Awesome.
Hey Adam! Wow, just last night I was sharing with my bro that what I did was like building a house, but yeah, I think you are absolutely right! Thanks for another incredible article.
Golden words man. Hats off