February 25, 2010

Learn TDD with Codemanship

If You Want Things Done Right, Manage Yourselves

Hello, there. Are you one of those people? You know the ones I'm talking about. They sit around in meetings all day. They have Blackberrys. They take 6 weeks to respond to an email, despite spending most of their time checking their inbox, and especially if it's from someobody unimportant, like a programmer.

That's right. I'm talking about managers. We need managers, right? Our project would go off the rails without a firm hand to guide it. I mean, how will the programmers know what code to write? How will the customer know what features to ask for? How will the testers know what scenarios to scrutinize? How will the software get deployed? How will new programmers get hired?

Underlying the need for managers on software teams is a set of assumptions that there are things that won't happen unless someone is there to manage them, and that there are important things only a manager can do.

Talk to customers? You need a manager for that. Schedule work? You need a manager for that. Hire a programmer? Yes, that's management business alright.

It's true that projects need accounting and budgeting and stuff like that. I have an accountant. He's called Geoff. He does my books and tells me off when I lose a receipt. Guess what, though? He's not the boss of me. He doesn't go out and speak to clients on my behalf. He doesn't win business for me. He doesn't decide what days I work. He doesn't have any say in when I take my holidays, or which graphic designer I should use for the Boffoonery programme (I did it myself in the end, by the way, because I'm cheap). I do all of this myself. He just balances the books at the end of the year and tells me how much tax Her Majesty's bloodsuckers will have to prise from my cold, dead hands.

I'm a programmer. No, seriously. And I can pick up a phone and speak to a recruitment consultant about sending us some CVs for a programmer role on my team. I can run a stand-up meeting and I can run a planning session with both hands tied behind my back. I can order stationary. I can put up whiteboards. I can tie my own shoelaces and wipe my own arse. Because I'm a grown-up. Well, maybe.

Having had one foot firmly in the UML and use cases camp for well over a decade I can certainly handle requirements, and can talk directly with the customer - who is also a human - and help them articulate what they need from the software without the need for a translator.

I understand business. I run one. I get invites to join the Institute of Directors and everything. And you say "oh, but that's rare among programmers". No. No it isn't. I've met a few programmers in my time, and despite a handful of very interesting characters who wouldn't function in any social situtaion - including working with other programmers - I'm confidently calling bullshit on that myth. Programmers understand business every bit as well as their managers. Possibly even better, since their managers haven't had to describe how their business works in bloody C++ or whatever. If you really want to test your understanding of something, try explaining it to a computer.

Projects need administators, just like my business does. I'm not a qualified accountant, and I need someone who really knows their stuff to make sure my books are tickety-boo and Mr Tax Bastard is fed the correct number of pounds of flesh. But I run my business. And hundreds of thousands of freelance programmers are in the same boat. They have to understand business, because they are one. And we spend our lives immersed in the customer's business to a level of detail the customer themselves probably doesn't go into.

I believe in self-managing teams of professional programmers. They can do the hiring and firing. They can work with the customer on requirements, testing and planning/tracking. They can order the stationary they need. And, very much an upside for them, they can decide things like how much refactoring is really needed, how much time can be invested in learning and practice each week, what documentation is really needed, and all manner of things that really are best left to the people who are actually doing the work.

And when they're too busy doing code and stuff (bearing in mind how much of their time would be freed up not having to persue pointless management agendas), they can send their Project Gimp to do it for them. Leadership can and often does come from within the team. A leader can be a programmer. And we can all be leaders at some point, when we're best placed to make certain decisions or provide a certain kind of direction.

And for those programmers among you who are thinking "but I don't want to do all this stuff"; maybe you don't, but if that's the case then stop complaining when your managers waste your time doing dumb shit (as they are wont to do). If you want a job doing properly...

April 16, 2009

Learn TDD with Codemanship

Twitter Re-Educates Me On "Value"

Twitter is currently teaching me a valuable lesson in - er - value.

Whenever I try to log into the service at the moment, be it via the web site, from my mobile phone or via TweetDeck, it's 50/50 that I'll actually get a response from the site.

If I am successfully logged in, when I submit an update it's 50/50 again that it'll actually get successfully posted.

Add to that some "logic quirks" with the functionality itself and some very dodgy AJAX nonsense going on, and we have one demonstrably flakey Web 2.0

And yet current speculation from those in the know (though the crisis in our financial markets maybe suggests that these people know nothing) values Twitter at some ridiculous, astronomical figure. We're talking the GDP of a small, but developed, economy here.

I am still convinced that a team of 4-6 good developers could deliver Twitter pretty much as it is on the Google App Engine in less than a fortnight. And deliver a far more reliable and robust implementation at that.

But how does the relationship between reliability and value work in this case? It calls into question the simplistic predictable relationship - a commoditised version of "value", if you like - that we've been assuming when we talk about things like "value streams" and "sustainable delivery of value".

If Twitter runs on just a few thousand lines of code, and I suspect there's very little under the bonnet in reality - then, if the service is valued in the billions, each line of code could be carrying the weight of millions of dollars in equity.

Imagine writing a line of code knowing that! How much time and effort would put in to making it right, and into making it scale?

Except, of course, Twitter's developers had no idea when they wrote it. And neither, I suspect, do any of us when we're writing code. No idea at all.


April 11, 2009

Learn TDD with Codemanship

Being Skeptical About Metrics != Dismissing All Metrics



There's a growing and vocal tranche within the software development community who believe that all software metrics are bad.

Curiously, they don't believe that metrics are bad when their doctor tells them that their blood pressure is abnormally high, or when their union representative tells them that their salary is below the national average for their job description.

But attach any kind of number to anything related to the business of writing software and it's a different story. Metrics, to some, are the Devil's work and must be exorcised from software development.

It's true that metrics can and often are abused in management. Decades of cooked books, skewed studies and notoriously optimistic "government statistics" have conditioned many of us to mistrust numbers. And rightly so. Whenever anyone presents you with a measurement, it's wise to be skeptical and question what it might mean and how it was collected. But dismissing all measurements as a rule is not skepticism. It's just as much an act of blind faith as believing every statistic you see.

Software development without metrics is woolly and very, very highly subjective. It's like the Olympics without stopwatches or cookery without a set of scales. Metrics debunkers sometimes paint a picture of the other extreme as being the reality of metrics - namely total reliance on arbitrary numbers, even when they fly in the face of our subjective reality.

I would not advocate blindly accepting what your metrics tell you. But I would definitely not advocate ignoring the numbers, either. If Max Planck had thought like that, we'd never have ended up with quantum mechanics, which - measured in terms of the accuracy of its predictions - is our most successful science. Sometimes the reality is what the numbers say it is, and not what our eyes or our instincts tell us.

And sometimes, and especially in very complex matters, simple measurements hide a more subtle truth, and our instincts serve us best - provided we've had the time to develop them to the point where they can be trusted. Estimating is a great example of something where the first instinct of a senior programmer is just as likely - if not more likely - to be right than any number derived through some kind of empirical COCOMO nonsense.

But that doesn't apply to every aspect of software development. If a coverage tool tells you that 50% of your code isn't executed during a test run then you know that 50% of your code isn't being tested at all. If a static analysis tool tells you that one of your methods has 500 lines of code and a cyclomatic complexity of 80 then you know it will be practically untestable and very difficult to change. If JDepend tells you that you have a package full of concrete classes that is very heavily depended upon then you know that making changes to code in that package is likely to have a bigger knock-on effect because of the lack of substitutability.

Sure. Absolutely. I won't deny that metrics throw up false positives and can sometimes send us on wild goose chases. But I'll tell you this: I have never seen a project team that delivered high quality software that wasn't monitoring quality using some kind of measurements. I suspect that's because testable goals tend to be easier to aim for.

By all means, be a metrics skeptic. Question every number you see. If a metric tells you something about reality, go look at reality and use your hard-earned judgement to see if you agree with the metric.

But dismiss all software metrics out of hand at your peril. Because I know that software teams who don't measure quality tend not to deliver very good software. Successful development teams use metrics. Of course, there are plenty of teams who don't measure anything and who think they're successful. There are plenty of people who think they have psychic powers, too.


February 17, 2009

Learn TDD with Codemanship

Contracts Obtained By Threats

Contracts obtained by threats or coercion (e.g, "we cannot begin development until you sign off the requirements") are as easy to garner as confessions by torture.

They are about as worthless, too...



October 13, 2008

Learn TDD with Codemanship

Productive Teams Are Business Assets. Recognise Your Investment In Building Them.

So here's a joke. You may have heard it before, in which case please don't spoil it for the other readers.

Q. How many weeks does it take your average OO software development team to ramp up to the point where they're delivering tested code, visible features and have build and test automation up and running? From a standing start? Does that include implementing a Agile process from scratch with a new team of people who've never worked together before? In a new office? On a client site (so you have no control over your environment)? How long would it be before you were delivering real features to the business?

A. It depends.

My own experience has been that just to be squirting out working, tested code of a provably high design and implementation quality from a standing start is that it can take a couple of months or more.

The list of things you have to get in place for that to happen is far longer than most of us tend to acknowledge. Everything from network access to source control to build automation to stationary (those story cards don't order themselves) and whiteboards. Just getting the room in shape can be a week or three of team effort.

Then there's the approach. Contrary to what you may have been told, we don't all carry around a book called "How To Develop Software" and arrive on teams with exactly the same understanding and outlook as each other about how to go about the business of writing code. It can take a lot of work - a lot of talking and debating and compromising (if you're lucky enough to work with a team that compromises, of course) - to reach a consensus on key practices and processes that the team will work to. That can take quite some time, too - especially if you want your finished approach to actually work. (We never really had that problem with RUP. We knew we were probably going to fail. But what the heck?! The documentation was going to look superb!)

And then there's the architecture. Oh boy, is there the architecture?! How long have you got? Back in the old days when men had fancy moustaches and fought to the death over the affections of some emaciated, disease-ridden debutante (those were the days, right guys?) life was much simpler. You slapped the cad about the face with your glove, proposed pistols at dawn and proceeded to blow holes in each other before repairing for breakfast at Mrs Miggins Tea Shop. Simplicity itself.

These days we crowd around whiteboards and throw loaded patterns at each other, until one of them explodes and we end up with Mementos all over us. Then we repair to our workstations and glare at each other for the rest of the project.

Anyway, it's an horrific, costly and potentially very time-consuming process. We're lucky if, by the end of it all, we've managed to agree a single thing - like that the code should run on a computer...

Add to this a million and one little gotchas - everything from tool and framework licenses to setting up Wikis to figuring out where to get a decent cup of coffee round here.It all takes time. And that time has to come from somewhere.

To get a team to a point where they are able to deliver anything of any value, you must invest tens of thousands - maybe hundreds of thousands - of pounds. And it is an investment. A productive team is an asset that has to be built up.

If you fail to recognise the value of that asset, you will make the mistake that so many employers make, which is that productive teams aren't worth preserving. All too often I see teams being broken up and laid off after a successful delivery, when - in reality - the team itself is every bit as valuable a business asset as the software they've created. (Often moreso.)

OK. So the punchline still needs some work...




September 20, 2008

Learn TDD with Codemanship

SPI - "Software People Inspiring"

I don't often meet people who actively disagree with the point of view that the largest factor in the success or failure of software projects is the people who work on them.

Fools who try to argue that "it would never have happened if we'd used Java", or who cite the lack of Scrum or Pair Programming or that they just weren't Unified Process-y enough, as the cause of their difficulties are missing the point somewhat.

If we'd got the right people, those problems would have melted into the background: a light drizzle over an ocean of skill.

Let's not forget that some of the greatest achievements in computer software were made by people punching holes in cards, following no visibly discernible process whatsoever. Perhaps a flow chart of their Software Development Lifecycle would include a "replacing vacuum tubes" phase, but requirements management, analysis and design, testing, change and configuration management and so on?

Not to say that these things don't make life easier. But history proves we can take off without them. Skill, creativity, imagination, dedication, and raw intelligence trump all of these and make the lion's share of the difference when we look at the quality of the end result.

I've worked with enough CMM Level 5 development shops to know that excellent processes can produce risible software. And anyone who's worked with Sun Certified this, Microsoft Certified that and IBM Certified the other will know that mastery of the technology doesn't add much value, either.

And in light of all this, as a consultant who often has to sum up what he does in the time it takes to take the lift from the top floor to the ground floor, I've been looking for a better acronym to describe what I do to replace S.P.I. ("Software Process Improvement"). Because that's not what I do.

I've looked at Agile-type phrases for it (e.g., "evolutionary capability improvement"), and I've looked at goal-driven versions like "software delivery improvement".

But the key word really is PEOPLE. When things get better in a software development organisation, ultimately it's usually because of people getting better at software development. Better individually, and better working together. Indeed, my whole view of "processes" now is that they are just descriptions of how individuals and groups of individuals can interact to achieve a shared goal.

I help developers to learn and improve, and I help teams to interact and collaborate more effectively. I do this mainly by encouraging them to care about what they're doing, and to motivate them to pursue their own learning and to actively share their knowledge. The specific practices, processes, tools and techniques always vary, and - for the most part - they teach themselves what they feel they need to know, while I cheerlead from the sidelines and hopefully inspire them to go further.

The acronym for what I do, then, is still S.P.I.

But now it stands for Software People Inspiring...







September 17, 2008

Learn TDD with Codemanship

Clear Up Misunderstandings - Get Practical

On occasion, we find ourselves in situations where we have to accept that the way we see the world and the way some of our team mates see the world are chalk and cheese.

That I can live with. We just agree to disagree, and move on into areas where - at the very least - we don't care either way.

What can make things much worse, though, is when we don't know that we disagree. We talk. We nod. we think we're seeing eye to eye. But when the time comes to turn talk into action, it quickly becomes apparant that we mean very different things indeed.

Take Model-View-Controller, for example. We can sit around and say things like "yes, let's just do your vanilla MVC implementation". All fine and dandy, you might think. (And who asked you, anyway?)

The fact is, there are now a bazillion ways of implementing MVC, the vast majority of which achieve none of the goals of MVC - but that's software developers for you, folks. And the odds are slim that a room full of developers will all be sitting there with exactly the same picture in their minds as they discuss it.

The best time to find out what people really mean is NOW. So get to practical stuff - whiteboards, spikes, pair programming - as soon as you can and don't waste too much time sitting around throwing the buzzwords around and fooling yourselves that you're all singing from the same hymn sheet.




September 8, 2008

Learn TDD with Codemanship

Continuous Recruitment & Hoarding Talent

It's the same old same old.

A gap appears in our (strictly hypothetical) development team and suddenly we're running around like headless chickens trying to fill it.

It's a desperate situation that we've created for ourselves. Because we only actively recruit when we have an urgent vacancy, we end up with whatever and whoever happens to be available at that exact time.

It's like last-minute Christmas shopping. We run around town at 4pm on the 24th of December trying to get something for everyone on our list. But all the good toys are gone and all the supermarket shelves have been picked clean of the good single malts and the best perfumes. You know your brother would really love that latest gadget: but they all sold out in November. So you make massive compromises, and your kith and kin get some pretty crappy presents. (But hey, it's the thought that counts, right?)

Some people are more organised than that. They think about Christmas all year round. They're walking past a shop and they see the perfect gift for Grandpa in the window, and - even though it's still February - they go in and they buy it, they take it home and they wrap it up all lovely and nice and then squirrel it away until December 25th.

Now why don't we hire that way? How long could you afford to keep someone really good on the bench before it just wasn't worth it any more? I genuinely believe that some software developers are ten times as productive as others, so if you found some really good, it might make commercial sense to keep them on the payroll for months before a real project comes up for them.

I think there's an equation here - a formula for proactive recruitment vs. reactive recruitment. I strongly suspect it will reveal that, in the medium-to-long term, it makes more sense to be constantly on the lookout for talent and to be rady to offer a contract there and then if just the right person comes along.

I know some fans of efficiency and Lean-ality will argue that keeping people on the bench is tantamount to a liability and that you should sweek to minimise such waste. But I'm afraid I totally disagree. You see, I believe that some waste - some latency - is unavoidable (necessary, even) to achieve responsiveness and to be able to adapt to chagning circumstances.

In situations where resources - like genuine talent - are this rare, you should hoarde. And if your business model makes hoarding talent impossible, then I'm afraid you will probably always be scrabbling around in the dust trying to find the least nasty compromise, and then paying dearly for it later.





September 2, 2008

Learn TDD with Codemanship

Last Call for SPA 2009 Submissions



Just a quick note for all you show-offs out there: there's are only 13 days left for you to get your session proposals in for Software Practice Advancement 2009.

As usual, I highly recommend attending, and I especially recommend leading a session. It's a very friendly and engaged audience and it's great professional experience.


August 31, 2008

Learn TDD with Codemanship

The Holy Grail of Realtime Feedback

The Holy Grail of software development is to find a way to directly connect the code we write to the business goals of our projects.

I've blogged before about a possible future where, as we type in the code, dials in our IDE flicker and present us with immediate feedback about higher issues like code complexity and dependency management, in the same way they currently do about syntactical correctness.

I'm finding it useful as a thought experiment to imagine what it wold be like if our IDEs could give us immediate feedback about the value of the code we're writing and the total cost of ownership it could potentially have.



Imagine that as I literally type in the code, dials tell me if I'm adding or subtracting value from the software and whether I'm adding or subtracting to the burden of of ownership. And squiggly blue underlines point me to problem areas while little messages pop up when my mouse hovers over them to steer me towards more valuable and/or cheaper code.

It's nonsense, of course. The kind of thing that pipe dreamers would poo-poo as cloud cuckoo land.

But it is just a thought experiment. And the goal of the experiment is to try and understand what kind of analysis we could do as part of the background compilation process that could possibly produce that kind of feedback.

Because if we understood that, then I suspect we will have learned something profoundly useful about software development.