People vs Processes and Tools
I recently attended a demo of a software tool for
After a few minutes showing the menus and screens, the demo became a
presentation of a slide deck about the software.
It turned out that the engineer demonstrating the tool does not use it himself.
His weapon of choice for requirements management is
Do as I say, not as I do.
Think of all of the situations where:
person/team/project doesn’t follow ‘the process’
person/team/project misuses or avoids using ‘the mandated/expected toolset’
... which boil down to an underlying
us vs them anti-pattern:
we are recommending/specifying the right thing, but they are doing
the wrong thing
Now, it seems to me there are only a few core reasons why someone would
do the wrong thing:
They don’t realise it is wrong: lack of experience, information, training,
They realise but don’t care: misaligned motivation or incentive
They believe that what we call ‘the right thing’ is actually the wrong
So for any given tool/process, maybe:
people are unaware of it, unable to find it, or unable to login to it
people do not understand it
people think it is broken, inefficient, over-complicated or not applicable
actually broken, inefficient, over-complicated or not applicable
That’s a whole set of potential blockers which can cause people to
...the right thing is to ignore the specified tool/process.
If we want people to actually follow our guidance, we need to remove all the
blockers. So I suggest that any tool/process we specify/recommend needs to
satisfy all the following:
easily discoverable; it is obvious how and where to find it
easy to understand and well documented; fast learners can figure most of it out
accessible with minimum friction e.g. no waiting hours/days/weeks for a login
works as described, and is generally applicable, efficient and fit for purpose
Maybe we should stick to pushing only
the tools and processes we actually use ourselves.
Who can we trust for software?
TL; DR We need to figure out how to guarantee that software can be trusted
In the over-simple graphic above, I've tried to map some of the key technical
roles being performed in the delivery and maintenance of complex systems and
services. I'm struggling to work out who ...
The Dalton Cycle
Thanks to Niall Dalton for this comment at the end of his post on
the trustable-software list
"I go off on this tangent to raise the whole bucket of pain involved in building a trustworthy system like this. Not that we necessarily want to try to build a 100% trustworthy ...
Trustable Software - Help Wanted!
For a whole load of reasons I think we need to get to trustable software, and
would appreciate comments and suggestions, preferably on the
which is public.
Note, I'm not "marketing" or "selling" anything here.
The aim is to trigger interest in a cross-industry set of grown-up ...
Are we there yet?
Many large projects are late. Most of the time the the actual journey turns
out to be much harder and much longer than it looked when we started out.
From a management perspective we are constantly looking for validation that
we're hitting the plan, whether it's traditional milestones ...
Technical debt for whole systems
"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." [Mark Twain]
If you've been in involved in large-scale software projects over the last few
decades you've probably learned the hard way that ...
Software Engineering As Legitimate Engineering Discipline
For 2016 I've decided it's time I take my public communications seriously.
Perhaps some of my customers and colleagues realize that my previous attempts at wit are born from decades of struggle on difficult software projects.
But most of the internet has no idea who I am, and ...
Why Should GENIVI Members Contribute, Again?
GENIVI Members need to make attractive, useful software to run reliably in cars for a long time. The amount of software needed is increasing faster than our capacity to bring in extra engineers, and our ability to increase the productivity of the engineers already engaged. Given the economics, automotive organizations ...
Leading Tools in GENIVI
I've had a stormy relationship with the automotive industry - love-hate doesn't begin to cover it.
It's not that I'm a car guy - I can barely manage an oil change. But cars these days contain a staggering amount of software. And in spite of what some may ...
Three Times Done
In my experience many organisations experience systemic difficulties in getting work 'done' to an acceptable standard. The Scrum solution for this is 'agreed definition of done', which typically leads to a checklist eg
the work has been checked in to the VCS
it builds ok
the automated tests pass
documentation ... Read More
Refactoring is an anti-pattern
I thought I'd written
more than enough words on refactoring already, but maybe I was too cryptic.
So here's my version 2.
Let's start by noting that most of the folks who claim that they are 'refactoring' don't actually know what it means.
I, on the ...
What does "BSP" stand for?
late-night drinking session technical discussion this week there was confusion about the meaning of "BSP" for Linux and Android.
Some folks think BSP stands for "Board Support Package".
But, as with
SCRUM, the popular view is wrong.
In the real world, BSP means
Bull Shit Project.
BSPs are ...
The Worst Metric
Lines Of Code is an awful way to measure software - but look at the pretty picture...
The software commandments
OK, I admit it - some of the Agile thinking
did influence the recent Software Commandments 2.0 update.
I accept short timeboxed sprints.
Agreed definition of DONE - great.
Prioritised list of requirements - awesome.
Daily standups - fine if you are all in the same room, and you stick to the rules ...
The best revenge...
Over the years I've worked with many amazing people, but from time to time I've also had to deal with some
complete assholes unpleasantness.
Frankly it's amazing at how downright dishonest, manipulative and plain stupid some folks can be.
Actually plain stupid applies to me too.
I predict the future of embedded Linux
I've been reading the excellent
Future Babble by Dan Gardner.
Perhaps unsurprisingly, it confirms that we're all wired as
complete idiots when it comes to looking into the future.
The science shows that the more confidently someone makes a prediction, the more likely they're talking utter balls ...
I believe in aeroplanes
How can you be sure that something is true?
Actually it is surprisingly difficult... Do I mean true as in fact or true as in 'I believe this'? Maybe we're in the matrix, and everything is a simulation... maybe the people you trust are lying.. or maybe they're ...
After a typically
ignored secretive softlaunch, I'm finally taking the wraps off devcurmudgeon. The idea is to be funny, incisive... and maybe change the world one hacker software developer at a time. But I'm not optimistic. This project may fail, like so many others :-)
Mostly I expect to ...
El Reg "not your grandad's project management"
I confess, I get a lot of my worldview from The Register... saves me coming up with my own jokes.
Anyway, was a little disappointed watching this...
Had to turn off when the Microsoft guy said "you have to build the business ...
My briefcase is older than you
I recently demonstrated my
desperation gravitas to a roomful of undergraduates with the immortal line "My briefcase is older than you." Disappointingly they continued fiddling with their gadgets.
Even my rollercoaster antics with Prezi failed to amuse...
But the exercise was not entirely a waste of time.
A spot of ...
Picking a fight...
Maybe I'm alone on this one ... but aren't Open Source and Agile pretty much directly opposed?
Agile = 5-9 people in a team, locked up together, everything thrashed out in face-to-face conversations, daily standups, timeboxed iterative deliveries.
Open Source = no fixed team size, distributed around the world, everything thrashed ...
I used to be in a band, when I still had enough hair for a stupid haircut.
We had real instruments. None of this electronic bleepy noises nonsense. We used to lug huge amplifiers everywhere, because the guitars always had to be loud enough to shake the building.
Whereas the ...
I need to get with the program. All these years working on secret projects with someone else's name on the mastheads have created an obvious problem - nobody knows who the hex I am.
There's an obvious solution too.
Why don't I just take my old ...
I don't like your code...
I mean it.
Refactor as much as you want, it will still smell of you.
Apple vs Contortionists redux
Previously I asked
"Does Apple use Scrum?"...
An ex underling just slipped me the recipe for Apple's secret sauce....
Wanna hear? Of course you do... you too could make gazillions... but you've got to promise not to tell anybody else.
It goes like this...
Three independent design teams ... Read More
Software Chaos Ridiculously Under Managed
So this post is just a place-holder for me to launch my new methodology - SCRUM.
I'd hate to have some fan copy my ideas (again) and find myself unable to prove categorically that I thought it first, so here goes...
Google tells me (so it must be true) that ...
Emperor's New Scrum... iteration 1
I've been wading through the literature on Scrum/Agile/Lean/Kanban/Hokey-kokey for months now, and I'm still no nearer to making sense of it...
How on earth can folks seriously believe that the whole commercial world should turn itself upside down so programmers can have an easy ...
On time and on budget - yeah right!
Developing complex software well is actually very difficult to do.
Seems to me it requires intelligence way above average, combined with enough pig-headedness to refuse to be defeated by dumb chips and other people's code spitting random error codes at you - often for hours or days at a time ...
Extreme programming 80s style - epic fail
My first brush with programming was on the
Sinclair Cambridge Programmable Calculator. A mathematics teacher got me hooked - if I remember well he was later knocked down and killed by a milk float.
Later I messed about on the
ZX80, ZX81, ZX Spectrum, and Sinclair QL while sailing gracelessly through ... Read More
After years of advising folks NOT to blog, tweet or display their
backsides innermost secrets on facebook, here I am poised to break my own rules. No doubt I'll come to regret it later, but really, I need to vent.
Later posts will explain why...