Software People Inspiring

First Auditions For Software Craftsmanship 2010 Point The Way

 

2010 brings a winter wonderland to much of Europe, and the first good auditions for Software Craftsmanship 2010 have been carried in on those freezing cold arctic winds.
David Laing has sent me a link to an already pretty slick-looking session on TDD for databases, which touches on lots of great stuff and utilises a good range of test and build expertise which I personally need to get my head around.



Emmanuel Gaillot has submitted a very interesting demonstration of the Robozzle kata in Haskell (not, I suspect, the last Haskell audition we'll see). A very good audition which I'm confident will translate into a great session.

Robozzle Kata in Haskell from Emmanuel Gaillot on Vimeo.

At this stage, formal auditions have not begun, except for coaches, but I very strongly recommend sticking your videos up and getting early informal feedback, as David and Emmanuel have demonstrated brilliantly here.

The SC2010 community site should be up and running in early February, and you will be able to join, submit links to your audition videos and vote on the other auditions posted and give feedback. Auditions will run through February to May, and you will be able to rehearse and refine and resubmit your auditions as many times as you like during that period before the final votes are counted and selections are made for the conference.

If you're interested in coaching a handful of auditionees each month to help them improve their sessions (and can spare 5-10 hrs/month), then I still have room for 2-3 more of you lovely, generous folk to lend a hand. In the spirit of egalitarianism, everybody must audition, including coaches. You don't need to be a master software craftsman, just confident that you know sh*t from shinola when it comes to practices like TDD and refactoring. Coach auditions need to be with me before February. 20 minutes of basic TDD or a bit of refactoring would easily suffice. Email links to auditions here. Coaches will get major kudos and a goody bag, and I doubt it'll look to shabby on your CV that you were an official coach at Software Craftsmanship 2010.

Keep those auditions coming!

Celebrate The New Year With Some Rubbish Demos I Recorded In 2009

 

And so we come to the end of another year. And what a year it's been! The first international conference on Software Craftsmanship. Boffoonery! in aid of Bletchley Park. And in those rare spare moments, and against all the advice of my elders and betters, Ive been recording demos of my really rather poor guitar music, which I present in their horrific entirety for your delight and delectation as a seasonal gift (or curse, depending on how you look at it).

These rough demos (very rough demos!) were recorded between Sept and Dec 2009 using RiffWorks, which I highly recommend for getting stuff down quickly without the usual "noodling" you get with Pro Tools, Cubase etc. Unless otherwise stated, guitar is an Ibanez RG2550Z (black and pointy, just the way I like them) and bass is a Peavey Cirrus through a SansAmp Bass Driver. I played all parts, except for the very sloppy bits, which were played by someone who broke into my flat and over-dubbed my originally faultless playing

Take No Pensioners

I've dedicated this fine example of demo quackery to my stepmum for her Herumphtieth birthday. The first track I did in RiffWorks,
and first track using the speaker-emulated output of my new Blackstar HT-Dual pedal.
The solo really sucks. Sorry, I just couldn't resist a bit of 80's Big-Hair-Open-Wah wankery.

Chunky's Revenge

More sloppy Big Hair wankery, this time in a Vai-esque lydian groove (you'll be hearing a lot of that, I'm afraid), with the HT-Dual and a nice clean sound courtesy of my Damage Control Liquid Blues pedal. Through a Damage Control Timeline tube-based delay pedal (the best-sounding I've heard). A lovely tubey lead sound. Must be all those tubes. Tubes still rule in metal!

Snakeskinned Alive

Wanky, wanky, wanky! Nobody likes this demo. Well, I do. But nobody normal. Used the Radial Plexitube pedal for a nice British sound through the POD X3 doing just cabinet/mic simulation. Like you care...

The Long Ride Home

All POD X3. 100% digital. I think there's a simulated Ibanez Tubescreamer in their warming up the clean sound. And lots of long delays and backwards guitar. No synths. All guitar. My feeble attempt at a David Sylvian/Robert Fripp-style affair

The Heavymetallist

This is my test track. I've done a demo with it four or five times to test different set-ups. This is the version I did after I discovered the amazing Recabinet convolution reverb library. I've never heard a better approximation of real guitar cabinet/mic combinations. For $15. Pity about the actual playing.

The Girl From Panama

I was drunk. It was late. My neighbours hate me. I was aiming for an Al Di Meola vibe. Well, sort of. If you listen carefully, you can hear the metronome ticking away at the end. Just a Yamaha CPX700 semi-acoustic through a Shure SM57 mic and massive reverb from the POD X3.

The Heavier Metallist

Tried to make a more atonal version of the Heavymetallist with insane distortion courtesy of the POD X3. "Tried" being the operative word.

After

Okay, so this is all HT-Dual and Recabinet, and I dusted off my metallic red Tokai Strat (they make better strats than Fender, IMHO). Yes, it's a big long lydian solo. Again. Wanky, wanky, wanky.

Pass The Napalm (On The Left Hand Side)

Recabinet + Damage Control Solid Metal in face-melting "Nuclear Mode". Your granny will love it.

Coroner-y

Recabinet + Solid Metal (at half-mast) in ill-advised attempt to recreate the minimalist sound of the eponymous Swiss metallers, complete with completely-out-of-place and very badly executed effect-laden solo

September Summer

Some acoustic stuff with a very slow jazz/latin feel and the strat doing the honours at the end. Just listen to that intonation. I'm not a qualified guitar tech. I know, it's hard to believe, but it's true. I was planning to add something, well, interesting. But lost interest.

Devin Sent ("The Man From Canada")

Dedicated to my Dad, who is from Canada. HT-Dual. Timeline. LOTS of delay. Then added a suboctave to beef up the sound using a TC-Electronic G-Major along with cavernous reverb in a vain attempt to disguise my awful playing. The final finish was some synth fairy dust courtesy of the stupifyingly powerful Omnisphere. My tribute to the actually talented Devin Townsend, who is also from Canada.

Value Is Not The Opposite Of Waste: Why I Don't Buy Into Process Improvement

 

If you've been a regular visitor to my blog since 2005, first of all, thank you. You may also know that I'm not the biggest fan of mechanistic or pseudo-scientific approaches to making teams better at creating software.

Which is why I don't buy into process improvement any more. At all. In all it's guises. TQM, BPR, Six Sigma, Lean. All old wives tales and hifalutin mumbo-jumbo, in my honest opinion.

Yes, there are the success stories that devotees and evangelists routinely point to. Usually in Asia. Mostly Toyota.

But anyone can find the exception that proves the rule. I can point to 80-a-day smokers who lived to be 100. In a wider sample population, there doesn't seem to be compelling evidence that process improvement makes a positive difference in the long term.

Commoditising "value" in this way, suggesting it can "flow" (and no doubt can be diced, sliced, weighed and stored for future use, like charcoal briquettes), seems very alien to me. "Value", in my mind, is a very complex and vague concept. There's fiscal value, of course. Profit. But businesses have been learning the hard way that such a one-dimensional view of what matters can lead to a very one-dimensional approach to management. Companies that are only interested in profits tend to be so at the expense of other kinds of "value", like satisfied customers, content employees, safe neighbourhoods, clean air, and so on.

Businesses have been learning, albeit very slowly and clumsily, that long-term success comes from chasing a richer, multi-dimensional and balanced set of outcomes. They are also learning that, like all multi-bodied problems, these outcomes interact and affect each other in complex ways. Who knew that improving the quality of your products could actually reduce costs, for example?

To suggest that this complex web of interconnected "things" can somehow "flow", to me, sounds as bizarre as proposing that "happiness" is rectangular for easy stacking.

The reality is so much richer and nuanced and unpredictable, of course. It is not like sorting out blockages in your plumbing, or hot-rodding an engine. A does not necessarily follow B.

The most damning indictment of process improvement is the widely-accepted fact that good developers tend to produce better software. All the tweaking and Six Sigma-ing and Lean-ing in the world won't make a piss-poor team appreciably better at delivering "value", any more than it could make an orchestra any better at playing Mozart.

Did it occur to anyone that the folks at Toyota just got better at making cars?

And it's not without it's unpleasant side-effects, either. Many methods focus on reducing "waste". Lean goes the whole hog and suggests that if we reduce waste, we improve the "flow of value". This has a very definite "profit vs. loss" feel to it. It is distinctly one-dimensional.

Complex systems need a fair dollop of waste. Waste might come in the form of unsuccessful prototypes, or a range of choices, or a level of redundancy. We only use 10% of our brains. Most of our DNA is "junk". Many species fail to flourish, ending up as food for the ones who do. Is anyone suggesting that removing 90% of my brain would make me smarter? Or that removing my junk DNA will make my childern healthier and stronger? Or that only successful organisms should be allowed to be born?

My point, laboured as it is, is that in many cases "waste" turns out to be there for a very good reason. In creative and innovative persuits, which are inherently novel and therefore unpredictable, who can say what will never be needed?

The adaptive capacity of a complex system necessitates some waste. Some choice. Some diversity. Some redundancy. Some slack.

In this respect, the likes of Six Sigma are effectively anti-Agile, if we interpret "Agile" to mean "responsive to change". If that's your goal, then focus on the people in your teams, and make plenty of room for their innate learning and adaptive abilities to work their magic.

You may now start throwing the furniture around.

Seeking Coaches For Software Craftsmanship 2010

 

Software Craftsmanship 2010 will be the premier international meeting of like-minded codesmiths; people who care passionately about creating high quality software and who dedicate themselves to getting continually better at doing it.

The exact date and place have yet to be officially confirmed, but I am aiming for it to be held at the birthplace of modern computing, Bletchley Park, in the south of England, in early July of next year. It will be a full day, with 3 tracks and a bonus Open Space track. Every single session will be hands-on and will involve live coding; something I believe is very much in the spirit of the craftsmanship movement. We will lead by example and learn by doing.

The submission and selection process will be unlike that for any software conference that I'm aware of. Prospective session leaders will "audition" for their part. They will record a screen capture of themselves performing the practical coding aspects of their proposed session, along with accompanying notes if necessary to explain the overall process. This will be posted online (there are many hosts for HD video now, and tools like Camtasia Studio and Jing make it possible to publish screen captures of considerable length in relatively small Flash files), and auditionees can submit a link to their audition on the SC2010 web site which is under construction.

We will begin accepting submissions in late January/early February, and you will be able to submit (and update) auditions right through until the end of May. Though there's nothing to stop you getting started straight away and posting your screen captures on your own blog or announcing it on your Twitter feed or Facebook page etc to garner early feedback from your peers and start rehearsing and refining your session.

Selection will be done by your peers. Anyone who submits to the SC2010 will be empowered to vote on the other submissions. The conference programme will be largely self-organising. As chair, I am reserving one 90-minute session in one track for the "Chairman's Choice" - which will be a session that didn't win out in the voting, but that I feel strongly should be included.

To aid in this whole process, I'm seeking generous and capable people to act as coaches to help 2-4 auditionees to refine their sessions. This will involve pairing (in person, or remotely using desktop sharing - so you can be anywhere in the world and still be involved) with each of your assigned auditionees once a month for about an hour. You will give them feedback and steer them towards the conference brief, which I will give you before we start the process.

You do not need to be a "master software craftsman" to be a coach. Indeed, I'm not a subscriber to the master-apprentice model and I know from direct experience that there is much to be gained from being coached by your peers. What you do need to be is a capable software developer (and I'm going to get a little prescriptive here and propose that "capable" in this context means you are effective in core disciplines including TDD, refactoring, OO programming and probably XP in general.) I am not looking for a Bob Martin or a Kent Beck. I am looking for somebody who knows their way around XP and is committed, enthusiastic, helpful, patient and encouraging.

I'm no Bob Martin or Kent Beck myself. But I am a professional software craftsmanship coach. And I derive huge satisfaction from it and am constantly learning in a way that day-to-day programming doesn't give me the opportunity to do. I highly recommend doing some coaching as part of your learning process. You could consider coaching for SC2010 as part of your journey to mastery.

I'll wager that "coached for Software Craftsmanship 2010" won't look too shabby on the CV, either ;-)

You will need to be able to spare 5-10 hours a month during the submission process (about 20-40 hours in total), starting in February.

To become a coach, in the fine egalitarian tradition I'm hoping to build on, you will also need to audition. Well, it's only fair, right?

This would not necessarily be a session submission, though. I need documentary evidence (a screen capture) that you know your onions well enough to work confidently with other craftsmen. Your audition need be only 15-30 mins in length, and demonstrate how you practice TDD and refactoring. I will need to see you work through a handful of tests and do a bit of refactoring as part of that process. I can follow most OO languages, so, unless you're working in something pretty unusual (e.g., Aspect COBOL), I should be able to understand your audition.

The deadline for coach auditions is now Jan 10th. You can email a link to your screen capture to jason.gorman@codemanship.com

FizzBuzz Java TDD Example Feedback

 

Just got a free moment before Zebedee tells me it's "time for bed" to post some feedback on my TDD illustration/example audition in Java/Eclipse:

I watched your presentation at http://www.parlezuml.com/tutorials/agilejava/fizzbuzz/fizzbuzz.html and here are some things that I found interesting about your style of TDD:

- The couple of mistakes you made (breaking test, infinite loop, 99 being Buzz) were useful to show how TDD finds problems, whether you made those mistakes deliberately or not. Having such things deliberately in a real presentation can be useful.

- It was refreshing to see the numberIsDivisibleBy method, because some time ago at StackOverflow I had done exactly the same and many people commented against it. :) See http://stackoverflow.com/questions/1060366/how-long-should-it-take-a-senior-developer-to-solve-fizzbuzz-during-an-interview/1060857#1060857 In my case, the code smell which triggered that refactoring was the additional parantheses in "if (number % (3 * 5) == 0)".

- I would not have created the *OneHundred method, since the parameterized method already expresses the intent and reads the same.

- Your style of writing tests is what I call "tests as examples" (or xUnit style). In order for somebody to find out what your FizzBuzz program does by reading the tests, he will need to read all the tests and reverse-engineer that why both 3 and 6 return Fizz (it becomes like an IQ test). The tests do not directly say that multiples of 3 will be Fizz.

The style of writing tests that I use, is what I call "tests as specification" (or BDD style). By reading just the names of the tests, it should be possible to understand the logic of the component under test. Even if somebody would give you only the test names ("the specification"), you could write the necessary test and implementation code and get the same result.

See the above StackOverflow link for how I named the tests for FizzBuzz. (Also I use underscores in the tests names for readability, as mentioned at http://www.infoq.com/presentations/10-Ways-to-Better-Code-Neal-Ford) For a non-trivial example of how I organize my tests, see http://github.com/orfjackal/tdd-tetris-tutorial (the "beyond" branch contains the most complete code).

-- Esko Luontola
www.orfjackal.net


Esko makes an interesting point about Behaviour-driven Development vs. vanilla TDD. The missing link here is triangulation. Namely that you may use more than one example to lead you towards a generalisation of a single behaviour. If you have more than one test for the same behaviour, you need a way to distinguish them in the test names.

You can also get into difficulties describing complex scenarios in abstract terms. I have some prior form in this, since I've applied formal specification techniques where we try to do exactly that. But people tend to understand things better from the bottom up, by wrapping their minds around a range of concrete examples, from which they can build a more abstract and sophisticated mental model.

Catalysis demonstrates this principle very powerfully in the modeling/UML world by using instance diagrams and filmstrips to explore examples before generalising to class models and the like.

Having done TDD and BDD, I have some personal insights into what works best for me. There's no right or wrong here. If you deliver better code and find BDD-style tests easier to follow, then fill your boots.

Auditioning For Software Craftsmanship 2010

 

The time is drawing near when I need to be thinking about Software Craftsmanship 2010.

What we know so far is that it will be some time in the summer of next year, very possibly early July. After a poll on this blog, it's also looking very likely the conference will be held at Bletchley Park.

Being a vain and ruthless dictator, I have decreed that talks and presentations are banned. So there'll be no keynote speakers, no Death By PowerPoint and no airy-fairy philosophical discussions about "what it means to be a craftsman". This is to provide much-needed relief from the many other conferences that seem to be largely dedicated to that kind of handwaving meta-meta-debate.

Software Craftsmanship will be about writing better code. End of. And those of us who wish to provide leadership on this topic will be encouraged to lead by example. Sessions will be practical, hands-on and will involve live coding. Wherever possible, sessions will enable practical, hands-on participation. Be that by demonstrating something and then asking delegates to have a go on their own laptops, or by asking volunteers to take a turn at the keyboard while the rest watch., or whatever.

The maximum sesson length will be 90 minutes, just like last year. But shorter sessions and demonstrations will be very welcome, too.

On-topic sessions will focus on practices and habits, providing any necessary underlying theory or discussion in direct response to what's happening in the code during the demonstration wherever possible. (E.g., an explanation of the Single Responsibility Principle could accompany a refactoring of an example of the Divergent Change code smell).

Demonstrations should be slick and well-rehearsed (for which we will make plenty of time during the selection process) and leave ample time for participants to - er - participate and have a go themselves during the session. For example, a one-hour session could start with a 15-minute demonstration, leaving 45 minutes for delegates to "do their thing" based on what you've shown them.

Selecting the sessions will be done by a process of auditions. If you want to submit a session proposal, you will need to do a desktop video capture of yourself performing the practical elements of your session, along with a short outline of how the overall session will work. This does not need to be slick and rehearsed in the first instance. It just needs to be good enough to clearly illustrate what you have in mind, and slick and rehearsed enough that it doesn't take 3 hours - or nobody will watch it in the first place! I recommend keeping your audition tapes under 1 hour.

There will be three rounds of auditions, starting in January 2010, and then in Feb and final auditions in March. This will give you two opportunities to rehearse and refine your auditions. We might expect an initial audition that takes an hour to be distilled down to maybe 20-30 minutes with practice.

There will not be a formal selection panel. Anyone who goes to the trouble of submitting an audition will be eligible to vote on the other auditions, as well as provide feedback to other auditionees that you can use to help improve things.

We hope that this will mean that, on the day, practical demonstrations will be slick, punchy and go smooothly, leaving more time for noodling and the inevitable interesing discussions that they will inspire.

The first round of auditions will officially open on Jan 1st and close on Jan 30th, so you have about 6-10 weeks to design and rehearse your first audition. Post your screen captures on HD-supporting video sites like Vimeo or YouTube or on your own web space. I post mine as Flash movies on my Libsyn space. As long as people can find it and watch it, it'll be fine.

I've posted an example audition of me doing the FizzBuzz TDD exercise (badly, I'll grant you), which lasts about 50 minutes and features me talking a lot of crap. If I were up for leading a session, which, as conference chair, I'm not, it would probably be fine. With 3 month's rehearsal, I reckon it would be a 20-mnute demo.

On Jan 1st you will be able to link to your audition videos from a special voting web site I'm sorting out. You can start posting your videos now, (I would if I were you. That way, you can start gathering feedback and refining your auditions earlier.)

Although there'll be no selection panel, I am going to be looking for up to a dozen mentors who will work with auditionees to help them refine their submissions. If you're an old hand or a new broom, and fancy coaching people to help them deliver a slick, well-rehearsed, interesting and useful session, then - in the spirit of the conference - you will need to audition for me. Email a link to your audition video to jason.gorman@codemanship.com. Mentor auditions will close on Dec 31st. As a mentor, you will get a special t-shirt which you can wear down the pub to impress the ladies (or gentlemen, depending on whether you male or female, or gay or straight, or bisexual, or transgender... oh, you know what I mean!)

Coaches will be free to submit sesson proposals once that process starts, too, of course :-)

A Little Practice Can Put You Head & Shoulders Above The Rest

 

I've played the guitar for 21 years, and during that time I've picked up a fair amount of technique and theory, and dabbled in a diverse bunch of musical genres from blues to metal and ambient to classical.

While I'm a very long way from being the world's greatest rock guitar player, even if I do say so myself, I'm not bad. Not brilliant. But above average for an amateur widdler.

Musical ability seems to follow somewhat of a power distribution. The vast majority of rock musicians know a few chords and can strum along to a few classics. Musicians who can play a passable blues solo and can get away with covering bands like Fleetwood Mac or Cream are an order of magnitude less common. Rock musicians who know some basic theory and have a bit of technique and can pick up more challenging stuff (e.g., Megadeth) are as rare again, and take some seeking out.

Rock musicians who would have the faintest clue what you were talking about if you told them "this is a D lydian augmented riff" are few and far between, but such knowledge only puts them a little above average ability.

To be better than most, you only need to practice 30 minutes a day - if you use the time well and don't waste it singing along to "Wonder Wall".

The same's true of programming. Ability to cut code also seems to follow a power distribution, if the hundreds of technical interviews I've sat in on are any indication. The vast majority of programmers are 3-chord wonders. And they're perfectly happy strumming along to the code equivalent of "Louie Louie" and earning an obscene amount of money doing it. 'Cause hey, folks like "Louie Louie".

A much smaller group of programmers read a few more books and try a few more "genres" of programming and pick up an extra language or two.

A comparitively tiny percentage read lots of books, try several programming languages and bother to learn some theory. And they practice. Maybe just for a few minutes a day, or an hour or two a week, but they sit down and they deliberately code something just to get the hang of coding it. They don't get paid for it. They do it entirely self-indulgently. Probably because they enjoy it. (Imagine that!)

In real terms they may be a bit better than average, but in numbers they are pretty uncommon. Maybe 1 in 100 programmers, if we're being honest, rise above mediocrity. I base this on experience of vetting candidates for programming jobs. 9/10 CVs go in the bin. Of the candidates who are invited in for interviews, 9/10 just aren't up to scratch.

Now, to a 3-chord wonder (and his boss), filtering out 99% of programmers looks like unnecessary snobbishness and elitism. But then, I guess, to many 3-chord guitar wonders, Eric Clapton is God.

But trust me, the 1% who got offered the jobs - if I had any say in the matter - weren't necessarily brilliant. They were good. Palpably better than average. They actually could do TDD to a serviceable level of quality. They actually knew some code smells and some refactorings. They had some vague idea what a class diagram meant. They could do a reasonable job of mapping an object model on to a relational database schema. They knew they were supposed to run the tests before checking in. They knew a little bit about how parsers worked. They could knock up a simple regular expression. They roughly understood how some basic sorting algorithms work. We're not talking C A O Hoare here.

And this is why, my merry chums, it makes absolutely no sense to be a 3-chord wonder. It's not that much work to be become better than average at programming. You just need to find an extra 30 minutes a day to sit down and try something new or work at bettering yourself at something you've done before.

You won't get good overnight. It'll take a few years. But you'll be part of that 10% of 10% sooner than you think. And push it a little further and you'll be in the top 10% of that 10% of 10%.

You could even get a special hat made. Now wouldn't that be dandy?

Skepticism Is What Software Development Needs Now

 

I've blogged in the past about the rather alarming amount of hearsay and pseudoscience in software development.

Today I tried a little social experiment. On a social network. Which I thought was fitting.

I asked on Twitter whether typing speed was a significant factor in programmer productivity. As far as I'm aware, there's no data on this, so the answer of a scientist would have to be "we don't know". You may have your theories about whether it would help with flow if you typed faster, or whether writing more code in less time would mean you make more mistakes and waste even more time fixing them. But none of these theories has been put to the test.

Bottom line is, we just don't know.

I got quite a mix of responses, many of which had similar theories. But few said those magic words: I don't know.

As it happens, there's a whole bunch of stuff we just don't know in software development. Most of the accepted wisdom can be traced back to proclamations made with little or no evidence to back them up.

Refactoring makes change easier? Does it? I mean, really, does it? Where's the evidence to support that?

Sure, there's plenty of anecdotal evidence. And I'm every bit as guilty of saying with an air of certainty that refactoring makes change easier and other spurious proclamations. But there's plenty of anecdotal evidence for alien abductions, faith healing and the Loch Ness monster.

Now, I'm pretty sure refactoring does make it easier to change software, if you do enough of it and do it effectively. But I have not a shred of convicing evidence for that. I just believe it. Very strongly. Probably as strongly as Tony Blair believes bombing civilians in Iraq was the right decision. He is very, very wrong. How do I know I'm not wrong about refactoring? I don't. I take it on faith. Which isn't good enough, really, I'm afraid.

If we're to distinguish ourselves from the loonies sittings out in the Nevada desert wearing tin-foil hats waiting for aliens to show up and give us world peace, we need to start adopting a more practical kind of skepticism, and start subjecting some of these old wives tales to a more scientific kind of scrutiny.

Our Goal Is To Minimise Coupling Between Classes. Not To Eliminate Getters And Setters.

 

As I'm sure Jesus and Marx would attest, publish and be damned.

There's always a danger when you make a point that's in any way nuanced or open to interpretation that the huddled masses will switch their brains off and choose not to think about what you've said, but to cut it down to a set of pithy, out-of-context, oversimplified truisms - often completely missing the point you were trying to make.

We're very guilty of that in software design. Why go to all the trouble of agonising about the many and complex design tradeoffs that need to be made to create high quality software when we can just learn a handful of soundbites which we can mindlessly apply regardless of the reality of the situation?

From the eponymous "GOTO considered harmful" to more recent design-isms like "singletons are bad" or "use dependency injection", there's no shortage of easy-to-learn rules and formulae we can follow that will exhonorate us from having to actually think about the code in front of us and what would be best for that.

Now I'm hearing a new design-ism: don't use getters and setters. I've watched discussions unfold on the Interwaste which display an alarming lack of insight or even a vague interest in why we shouldn't be using getters and setters.

And, let's be frank, just as with GOTO, singletons and dependency injection, it completely misses the point. Our goal is to minimise dependencies between classes and to maximise the internal cohesion of classes. We want to put the behaviour where the data is, and we want to avoid wherever possible sharing data between classes.

But, just like income tax, we can't avoid it altogether. If we can't share data between classes, then we'd have to put everything - data and behaviour - in one big class. You cannot have modularity and reuse without sharing something. So there's a trade-off that must be made.

The "tell, don't ask" school of design requires us to favour interactions between objects where A tells B to do X, and B has everything it needs to do X. As opposed to A asking B for all the data needed to do X, and then having A do it.

A simple example would be to have a Java servlet use getters on a Customer object to retrieve the customer's first name, last name and title (Mr, Mrs, Dr etc) and then concatenate them together to give the full name for display. Since Customer owns that data, such behaviour arguably belongs in Customer, not in the servlet.

But if the same servlet wants to format an HTML table containing the customer's first name, last name and title then that might be a different situation. I would argue that this is a clearly seperate responsibility relating to what the servlet knows about, and doesn't belong in the Customer class. So how does the servlet get hold of these bits of data without using getters?

Does it pass in a TableFormatter object with an InsertData() method that the Customer object can call with first name, last name and title? That seems like quite a wanky solution to me.

There are times when getters are needed. You may come up with some clever method names to try and disguise your getters. But they'll be in there somewhere. End of.

That we seek to minimise those occasions is important. But our goal here is not to eliminate getters, and it's vitally important that we remember that.

Scrum or Kanban? Pick One And Get On With Delivering Quality Code!

 

I'm getting increasingly vexed by this unhealthy obsession with planning and project management, especially among the Agile community.

The likes of Scrum, Kanban and other variations of the put-stuff-into-some-kind-of-prioritised-work-queue-and-pick-new-work-from-the-top theme have become an obsession to the point that one could be forgiven for thinking that this is what software projects are all about.

They are not optional, of course. You need the work queue. It needs to be effectively prioritsed. You need to track progress as objectively as possible. It needs to be highly visible and transparent. And you need the customer to drive all of this.

But these are no-brainers. There's an inescapable logic behind them, and they should take mere minutes to learn to a practical level where they can be successfully applied.

Writing reliable and maintainable code, on the other hand, takes years to master. And I see increasing numbers of teams who are so caught up in the whole planning and project management aspect of their work that they lose focus on bettering themselves as programmers. Indeed, many of them fall so in love that they cease to be programmers and instead travel the land as disciples of their chosen methodology, spreading the good word to hapless other teams, who in turn become infected with the Scrum/Kanban meme.

That these practices are so very easy to learn is what makes them so virulent. And, if done right, they do help. They help a lot. There's no questioning that.

But if you are churning out crappy unclean code, they don't. Agile relies on code being easier to change. If it is complicated, riddled with duplication and unmanaged dependencies, lacking regression test assurance and basically cobbled together under the relentless pressure of a Scrum or Kanban drumbeat (Kanban's beat sounding a bit more like free-form jazz, obviously), teams will inevitably hit the barrier of increasing software "viscosity" and all their brilliant planning and tracking will just reveal for all to see how quickly productivity is slowing down.

You cannot deliver a continuous stream of anything if your bad habits keep clogging up the pipes.

So clean code is a prerequisite of Agile project management. Teams must focus 90%+ of their effort on to delivering higher quality code, and not waste their time obsessing about whether they should estimate using Fibonacci numbers in their Planning Poker sessions or what colour index cards they should use for reporting bugs.

I'm not saying these things aren't important. But they are practically trivial and easy to master, and they'll mean diddly-squat if you aren't keeping a very tight reign on code quality.

There. I've said it.