Long long ago, at an Agile summit in Utah,
a group of software industry veterans, frustrated by what they saw
as overly heavyweight software processes, concocted the
Manifesto for Agile Software Development:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
... and so the "Agile Transformation era" began:
The Agile Alliance formed, conferences were held,
companies went mad wanting a bit of this, everyone was having standup meetings,
burndown charts, product backlogs, Agile coaches all over the place,
more Agile coaches than developers ...
and Post-its, Post-its, Post-its everywhere.
The more Post-its you have the more agile you are.
We spent ten years talking about people, interactions, team building, eliminating waste ...
and at some point agile took a detour ... process became more important than technical practices ...
everyone went crazy at the Post-it party, three years later they woke up
and realised that every two weeks we see the pile of s#?! getting bigger.
-- from Software Craftsmanship talk by Sandro Mancuso (2:00-5:00)
Uncle Bob proposed adding the assertion
that we value "Craftsmanship over crap" to the manifesto
-- Uncle Bob, craftsmen and the Agile Manifesto
Around 2008, some of the original Agile Manifesto-istas, led by Robert C Martin (aka "Uncle Bob"),
felt that Agile had gone off the rails, with too much emphasis on process
rather than technical practices and code quality.
This group felt that Agile projects, every two weeks, relentlessly, steadily, iteratively,
were producing more and more crap code.
Adding to technical debt. Slowing us down.
Though Agile gave good feedback on many things, code quality was not one of them;
it is not visible on burndown charts or the Scrum board.
How does this happen?
Well, there seems to be an unwritten law of the Daily Standup
that every morning you have to move at least one Post-it note.
To comply with this "law", I sometimes pick up the Post-it note I was working
on yesterday and move it a few millimeters to the right on the Scrum board
while explaining why it is
not really done yet.
I always feel bad when I do this though; I would much rather
proudly proclaim that it is done, so as to publicly show-off how productive I am.
Sadly, I've often noticed folks succumb to this psychological pressure
to proclaim something done
when it is not ... resulting in an every increasing pile of poo,
as illustrated by Sandro's next (pair programming) anecdote:
"but what about these names, they don't make sense ... and there's lots of duplication ... and ..."
yeah, well as it's almost done now let's just check it in and add that to the technical debt backlog.
This was a brand new feature in an agile team!
The guy (Sandro was pairing with) was writing brand new code already thinking
to add stuff to the technical debt backlog!
-- from Software Craftsmanship talk by Sandro Mancuso (5:30-6:20)
How to fix this lamentable state of affairs?
The new Software Craftsmanship group chose to add four new Software Craftsmanship principles
to the original Agile manifesto, creating a Manifesto for Software Craftsmanship:
- Not only working software but also well-crafted software. Code we can refactor confidently and without fear.
- Not only responding to change but also steadily adding value. Not just bug-fixing, but improving code structure, relentlessly keeping it clean.
- Not only individuals and interactions, but also a community of professionals. Mentoring, sharing, user groups, passion, professionalism.
- Not only customer collaboration, but also productive partnerships. Not a "manager giving orders to a developer" relationship, rather a partnership of equals built on trust.
Well-crafted Software
God forbid that we have one day someone who is a Software Craftsmanship coach
... it is about lead by example, being a mentor
... not about beautiful code, just trying to provide value, not writing crap code for your customers.
The lack of craftsmanship can be one of the main causes of failing projects.
-- from Software Craftsmanship talk by Sandro Mancuso (30:00-31:00)
Like Sandro, I disagree with the view that "Software craftsmen just care about beautiful code".
Today, for example, it took me quite a while to figure out
why some code that "should" fail was in fact reporting "success".
I almost fell off my chair when I finally realized that it
was silently catching and throwing away all exceptions!
No comment explaining why it would do such a bizarre thing.
To me, this sort of sloppiness shows a basic lack of respect for your colleagues;
lack of care and comments wastes their time.
It is unprofessional. Nothing to do with beautiful code.
Steadily Adding Value
After five years, the software is so s#?! that in the beginning
it took two days to add a feature
a feature of the same size now takes two months ...
so they write a brand new one that is as s#?! as the previous one
that will also be decommissioned in five years time.
-- from Software Craftsmanship talk by Sandro Mancuso (17:00-18:00)
Now the two teams are in a race.
The tiger team must build a new system that does everything that the old system does.
Not only that, they have to keep up with the changes that are continuously being
made to the old system.
Management will not replace the old system until the new system can do everything
that the old system does.
This race can go on for a very long time. I've seen it take 10 years.
And by the time it's done, the original members of the tiger team
are long gone, and the current members are demanding that the
new system be redesigned because it's such a mess.
-- Robert C Martin in Clean Code (p.5)
The only way I can see to avoid this sort of fiasco is to
to have the discipline to always keep the code clean in the first place,
relentlessly refactoring as required every time you add a new feature.
Productive Partnerships
As soon as the button was pressed to mute NASA from our meeting,
the managers said "we have to make a management decision", said Boisjoly.
The general manager of Thiokol turned to his three senior managers and asked what they wanted to do.
Two agreed to go to a launch decision, one refused.
So he (the general manager) turns to him and said "take off your engineering hat and put on your management hat" --
and that’s exactly what happened, said Boisjoly.
He changed his hat and changed his vote, just thirty minutes after he was the one to give the recommendation not to launch.
I didn’t agree with one single statement made on the recommendations given by the managers.
The teleconference resumed and NASA heard that Thiokol had changed their mind and gave a recommendation to launch.
NASA did not ask why.
I went home, opened the door and didn’t say a word to my wife, added Boisjoly.
She asked me what was wrong and I told her
"oh nothing hunny, it was a great day, we just had a meeting to go launch tomorrow
and kill the astronauts, but outside of that it was a great day".
-- from Remembering the mistakes of Challenger
As indicated by the appalling "management decision" to launch the Challenger Space Shuttle,
the lack of a true partnership, built on trust, between technical folks and management can
have truly tragic consequences.
Under pressure we cut corners ...
No one wakes up in the morning and says "today I'm going to screw up,
today I am going to write the worst code I can possibly write,
I'm going to f#?! up with this company" ... I met some people who did that,
but normal people don't do that ... everyone is trying to do a good job.
The business asks how long is it going to take? ...
The pressure we keep talking about, the pressure we put on ourselves
... we think we don't have time, even when we have the power to go to the business
and tell them how long something is going to take!
-- from Software Craftsmanship talk by Sandro Mancuso (7:00-9:00)
A Community of Professionals
Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have
shown it takes about ten years to develop expertise in any of a wide variety of areas,
including chess playing, music composition, telegraph operation, painting, piano playing,
swimming, tennis, and research in neuropsychology and topology. The key is deliberative
practice: not just doing it again and again, but challenging yourself with a task that
is just beyond your current ability, trying it, analyzing your performance while and
after doing it, and correcting any mistakes. Then repeat. And repeat again.
There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4,
took 13 more years before he began to produce world-class music.
-- from Peter Norvig's Teach Yourself Programming in Ten Years
As indicated by Norvig above, it takes time and effort to become an expert, a true software craftsman.
There appear to be no real shortcuts.
With the current trend towards generalists in agile teams,
finding the time to become a craftsman can be problematic as you
find yourself constantly switching from one domain to another,
from one language to another.
This also affects code quality in that most code is being written by generalists, i.e. non-experts.
This will be the topic of the next installment in this series.
Other Articles in This Series
External References
Perl Monks References
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
