Agile teams are neglecting design.
I can already hear your objections. Surely, you will say, many Agile teams these days do test-driven development and TDD is all about design. I absolutely agree, after all, I dare not question Uncle Bob who, in his “Agile Principles, Patterns, and Practices in C#” book clearly says
“The act of writing a unit test is more an act of design than of verification”.
The problem, however, is not if we are doing TDD but how we are doing it. Writing unit tests before production code, watching the tests fail, writing corresponding production code until the test passes and then refactoring requires discipline. Many new Agile teams lack that discipline. To gain the full benefits of TDD also requires a lot of practice and teams may simply have not had the time to accrue enough.
These two obstacles aside, I still don’t see the practice of TDD shaping the design of teams’ code in a way that Steve and Nat describe in their excellent “Growing Object-Oriented Software, Guided by Tests” book. I think among the reasons sits this one: frameworks.
I see this time and time again: a new engaged, eager and energised Agile team sits together to start a new project. They want to break away from the old ways of working. They have already been freed from the heavyweight processes which required lengthy documents, endless approvals and then subjected them to a stream of bugs arriving weeks or months after they last touched the affected code. They also take this as an opportunity to break away from the technical baggage accumulated over the years. Not doing so would be to neglect the Conway’s law.
And then what does a team do? They pick a framework. Chances are, if you are an Agile team writing a website in .Net you will go for the ASP.NET MVC framework. If you are trying to move away from the monstrosities of Java Enterprise frameworks or got tired of Spring you might be moving to grails. If you are more daring you drop you old technology altogether and pick rails. Add an ORM on top or something from the NoSQL pallet and your fresh new architecture is ready waiting for you.
While there is absolutely nothing wrong with these frameworks and technologies, making such choice means you have given up design decisions that you would have otherwise had to think about. You start working within a framework and then your thinking re-focuses to consider how best to fit your problem into the skeleton which is already in place. It might be slightly awkward to write some of the unit tests but you just blame that on your inexperience with the new technique.
Isn’t it ironic, that as we free ourselves from the rigidity of the organisational processes we are willing to subject ourselves to the rigidity of the framework structures.
In the short time, we go astonishingly quickly, new functionality flows into releases, new pages appear, database expands magically and there is none of that old hand-crafted SQL to worry about. Many Agile teams are probably still at this stage. The will go on to neglect design, they won’t question the structure of their code at various levels, they won’t reevaluate their architecture. Then strangely, release by release, they start to slow down. Features become more difficult to implement, changes solidify, codebase stagnates.
I just hope it’s not your team.
I can still hear J.B. audaciously whispering “Shift+F10“whenever I would reach for the mouse to run a suite of tests in IntelliJ. Although we worked together a while ago the sound of his voice still reverberates in my head and has since prompted me to make a step improvement in the use of keyboard short-cuts in the IDEs.
I used to think keyboard short-cuts where mostly for the black-hat ninja coders who spent their entire lives immersed in code. I was happy enough with Ctrl+C and Ctrl+V, perhaps a Ctrl+Shit+B at times. Everything else was there visibly accessible with a swift move of a mouse. I didn’t worry about the pause to grab it, after all we all know typing is not the bottleneck.
What I have now realised, is that using keyboard short-cuts is not only about speed or dexterity. It enables you to tap into a very useful mechanism of our brains – the muscle memory. When you reach the level of unconscious competence executing commands or operations no longer requires a context switch of going from the keyboard and thinking about the problem to the mouse and locating the GUI elements on the screen. You save precious mental cycles and more importantly don’t interrupt the flow of thoughts thus helping concentration and ultimately improving the quality of what you deliver.
I have been doing quite a bit of grails development recently and used IntelliJ IDEA IDE. In many respects it is a very good environment (as good as IDEs can be), for me more friendly and usable than NetBeans or Eclipse.
One of the features I really like is the clipboard stacking which allows you to paste from your clipboard copy history.
Now I’m back doing some work in Visual Studio 2010 and I was looking for similar functionality.
Out of the box VS2010 support the CycleClipboardRing option (Pastes an item from the Clipboard ring to the cursor location in the file. To paste the next item in the Clipboard ring instead, press the shortcut again) with CTRL+SHIFT+V and CTRL+SHIFT+INSERT as keyboard shortcuts. I found it slightly confusing and not as useful as the IntelliJ equivalent.
Fortunately I have ReSharper installed (I struggle to do any work without it in Visual Studio anyway) and it has the very same feature as IntelliJ – look in the menu under ReSharper > Edit > Paste.
To take full advantage of it, I just swaped the default Visual Studio shortcut for the functionality provided by ReSharper by associating the ReSharper.ReSharper_PasteMultiple command with the right shortcut (under Options > Environment > Keyboard).
Now my clipboard is useful again.
Three months ago we got a small gadget from our energy provider – a smart meter. I didn’t think of it much, but we’ve got it up and running and located it on the kitchen worktop right on top of the coffee maker. The coffee maker is broken anyway but it serves as a good stand and makes the new toy difficult to miss when going around the kitchen business.
The meter itself is fairly simple, it shows the current energy consumption. It also lets you set a daily target for energy use. It then displays how you’re doing against your target today, how you’ve done yesterday and over the last week. Since now the information was there and available to us, we started looking. To my surprise the single most demanding consumer in the house turned out to be the kitchen lighting. Upon reflection, twelve 50W halogen lights turned on for at least a few hours every day do need a lot of energy.
Now that the kW were flashing right in front of us we had a good incentive to change our habits and it proved very simple too. Just turn the light off when you leave the kitchen – a glance on the meter and you know why. Within a month we started saving energy. With the first wave of improvements were able to look further and decided to replace halogen bulbs with LED equivalents.
Today, only three months later, we are using 40% less energy and this improvement was neither costly nor difficult and we can still do better, all thanks to a simple feedback mechanism from a useful gadget.
The same principle applies to software development and works very well. Using information radiators, big prominent boards with relevant data, is invaluable in driving improvement efforts. It is also possibly the easiest way to initiate a change and is why Kanban proves so popular recently.
So make the invisible – visible.
By the time my own copy of “97 Things Every Programmer Should Know“, edited by Kevlin Henney, arrived I have already seen a few copies around and heard a few people’s opinions. I was quite keen to reflect on some of the wisdom shared by the contributors so I picked it up for the summer holidays and got going.
As I was reading about automation, simplicity, boy scout rule or code comments my initial reaction was lukewarm. Surely these are all interesting articles, I thought to myself, but feel familiar, perhaps even obvious; maybe an interesting read for a beginner. I wasn’t sure what I could really take away from the book apart from a few ideas I have not come across before.
I think I would have read through and put the book back on the shelf, just to affirm myself as a decent developer since these things all looked familiar, if it wasn’t for the entry by Jon Jagger – “Do Lots of Deliberate Practice“. Only once I read it did I realise that perhaps I have something rather different in front of me than I initially thought. Perhaps it is more than just a collection of thoughts, ideas, best practice that I could refer to.
I realised, that what I actually have is an excellent collection of exercises that are a perfect starting point to do more deliberate practice with. Ideas that I might know about but ideas which are only truly valuable if I can act upon them. Now I have a great source of inspiration and direction that I can pick from and think how can I apply each and every pearl from the book in my everyday actions. How I can deliberately practice being a better programmer.
I must remember though not to simply perform those tasks to complete them but to do deliberate practice to improve my ability to perform them. I’m setting off to turn 97 things every programmer should know into 97 things I, as a programmer, do and so should you.