Warning: This article contains strong language that may offend some readers. Please blame Uncle Bob.
If the sentence "Don't Ship Shit" doesn't ring a bell, then be sure to watch Uncle Bob's talk about professionalism and delivering quality software first.
The particular episode of Uncle Bob's talk I like to discuss in this post is the one about the two sets of ears picking up the tagline:
"I expect that we will not ship shit".
Bob pictures this like this: while the ear of the programmer is yelling at you saying this is insane, the ear of the normal human is saying this is completely reasonable. Basically, Bob states that programmers believe it's impossible to deliver quality software while meeting deadlines unless they ship shit.
Without any doubt, Uncle Bob is a great speaker, and the Voxxed CERN 2019 Keynote is an excellent presentation. The story is so recognizable, making the talk so enjoyable. Yet, at the same time, it's also painful because it's so true. As developers, we know we're often cutting corners so big that it results in poor-quality software. The boundary between cutting corners and crappy software is thin. On the other hand, business seems unaware of these shortcuts and assumes developers always deliver top-notch applications and services 😦
I want to elaborate a bit more on Bob's talk: I think they're actually two kinds of shit: Shit by Design and Shit by Incompetence.
Shit by Design
Shit by design: shit caused by overcutting corners and being too indulgent.
Bad design driven by wrong estimates
I can't repeat it enough: estimations should be accurate but not precise. Also, estimates are non-negotiable. You should feel offended if someone questions your estimates!
Don't cave under pressure to make silly estimates!
Bad design by bureaucratic meddling
Business defines the functionals, IT defines the non-functionals.
Compare writing software with buying a car. As a customer, you can decide upon a wide variety of options. However, a customer can't choose to leave out the airbag or seatbelt to save some dollars. Manufacturers don't offer that choice because the law doesn't allow or to protect customers against themselves (in case somebody is still to be convinced those things are a lifesaver in case of an accident) 😓
Don’t let businesses decide on the non-functionals. IT will feel the pain of those when they are not properly executed. Security can be compared with a car's seatbelt, it's not optional.
Bad design by feature stuffing
Designing a system without knowing RTO and RPO inevitably results in over- or under engineering. Besides, software quality assurance is not a one-off. Continuously use your SLOs as a defense shield against feature stuffing and to reserve enough time for the non-functionals.
The key takeaway: be more assertive as a developer. No one expects you to take shortcuts so big that they ruin quality and SLOs!
Shit by Incompetence
Shit by Incompetence: people not being aware of the mess they're making.
In Bob's words: we don't know shit. 😄
There is nothing as dangerous as the Dunning–Kruger effect: failing in self-assessment and overestimating your abilities. Personally. I like Socrates' saying: I know that I know nothing. That mindset is a good starter and half the battle!
In a nutshell: don't over- or underestimate your skills and be assertive! That's the best defense against shipping poor quality software.
Enjoy and until next time!
Top comments (0)