July 18, 2017

Learn TDD with Codemanship

Why Don't We Eat Our Own Dog Food?

You may already know I'm a big advocate of developers eating our own dog food.

Using the software we create as real end users, in the real world, provides insights that no amount of meetings or documentation can provide.

A quick straw poll I ran on Twitter suggests 2 out of 3 of us haven't actually used the software we're working on for real.



I've been banging this drum for years, for a largely reluctant audience. Managers say "Our users aren't happy with the latest release" and ask me what can be done. And I say "Walk a mile in your customer's shoes". And they say "Thanks for that. But no."

It's such a simple thing to do, and yet somehow so very hard. There's something psychological going on, I reckon. The same reason most hotel chain employees have no idea what it's like to be a customer in their own hotels...

I urge you to try it. Now.



July 16, 2017

Learn TDD with Codemanship

Developers & Employers Prefer to Connect Through Networks

I ran Twitter polls on developers' preferences for finding work, and employers' preferences for finding developers.






There's significant alignment. Both devs and employers prefer to connect through their networks - employers apparently more so.

This makes a lot of sense. There's the benefit of "it takes one to know one". And hiring devs who already know your devs may mean a better team fit.

It raises the question of how people who aren't in those networks find opportunities. This has implications for diversity. Hiring entirely through networks could lead to an effectively closed shop.

We should think about how to extend our networks to include people who might not normally be included. For that, we probably need outreach.

Noted also just how little devs and employers think of agencies. This comes as no surprise, when you've been in the industry as long as I have and heard many complaints from both sides.

Handing responsibility for hiring highly skilled workers to someone with no understanding has obvious drawbacks. You may as well ask your greengrocer to do it..

How IT recruitment agencies survive - and thrive - in a market that sees little value in them? It's a mystery for sure. There are just so many better routes now.

I think it boils down to the interpersonal. Sales people in these agencies build relationships with people working in client organisations. It's that simple.

As rational as we like to paint ourselves, we are - in essence - just shaved apes. "Yes, there may be better ways of hiring. But Phil from Computer Bastards Ltd bought me dinner. So they get the job."

That may well change, though. Social media's making it easier for these communities to find each other. As with so many other markets, the Web could end up cutting out the middle man.



July 9, 2017

Learn TDD with Codemanship

Why You Should Put Learning Opportunities Front-And-Centre In Dev Recruitment



A little Twitter poll I ran under the Codemanship acccount seems to confirm something that many of us have been saying for years. 41% of those polled said they could be lured from their current job by greater opportunities to learn.

Software development is a career that involves lifelong learning, and lot's of it. That's how we progress. So it doesn't come as a surprise that it was ranked significantly higher than "More money".

It's surprising, then, that learning opportunities don't figure higher in dev recruitment campaigns. I've banged this drum with clients many, many times. Want to attract and retain great developers? Make learning - mentoring, conferences, training, time to read, time to share - a greater part of the job. No, scratch that. Accept that learning is the job, and build your team culture around that inescapable fact.

When you're hiring, don't just look for what they know now. Look for their potential to learn. And their potential to teach (e.g. by example) the stuff they know so others can learn from them. And clear the way for that to happen. A lot.

Sadly, such employers are too few and far between. The unreasonable and unrealistic attitude that developers should arrive knowing everything they need to know, and no learning should go on on company time, is a leading cause of developer attrition.

It's also the reason why you've been searching in vain these last 6 months for a fluent Mandarin and Dutch-speaking full-stack JS/Node/Java/Clojure/Ruby/NoSQL/SQL/Docker/COBOL/Eiffel/Vim/Linux/Windows developer who has an HGV license and is licensed to practice medicine (salary: market rate).

Software developers tend to be highly educated, but the most important thing we learn is how to learn and it's one of the most important skills your money can buy. In return, one of the most valuable perks you can offer them is more opportunities to learn.

As a professional trainer and mentor, I am of course biased. I tell devs what I do, and they say "Wow, you must be really busy!" and I say "You'd think so, wouldn't you?" But the reality is that the majority of employers don't offer their devs any training at all, let alone time to, say, read a book.

The kind of bosses I run training for are unfortunately very much in the minority. Although, interestingly, they seem to have a lot less trouble hiring good developers.

Funny, that...


July 4, 2017

Learn TDD with Codemanship

Are We Only Pretending To Care About Cost of Change?

Wise folk have occasionally told me - when I've claimed that "I really wanted X" - that, if X was within my control, then I couldn't have wanted it badly enough or I'd have X.

You know, like when someone says "I really wish I knew Spanish"? Obviously, they really don't. Or they'd know Spanish.

Likewise when development teams say "I really wish we understood our end users better". Evidently not. Or we'd understand our end users better.

And, talking about it today with colleagues, there's a nice little list of things development teams are only pretending to care about. If they did, they'd have done something about it.

Take the cost of changing code. Is your team tracking that? Do you know how much it cost to add, change or delete a line of code for your last release? Do you know how the cost of changing is, well, changing?

The vast majority of teams don't keep those kinds of records, even though the information is almost always available to figure it out. Got version control? You can get a graph of code churn. Got project management or accounts? Then you know how much money was spent during those same periods. Just divide the latter by the former, and - bazinga! - cost of changing a line of code.

The fact that most of us don't have that number to hand strongly suggests that, despite our loudest protestations, we don't really care about it.

And what's very interesting is that it's no different within the software craftsmanship community. We talk about cost of change a great deal, but I've yet to meet a self-identifying software craftsperson who knows the cost of changing their own code.

This seems, to me, to be like a club for really serious golf enthusiasts in which nobody knows what their handicap is. At the very least, should we not be building a good-sized body of data to back up our claims that code craft really does reduce the cost of change? It's been nearly a decade since the software craftsmanship manifesto. What have we been doing with our time that's more important than verifying its central premise?



June 10, 2017

Learn TDD with Codemanship

Could You Be A Mentor To An Aspiring Software Developer?

I've been beavering away these last few weeks putting together the basis for an initiative that will enable experienced software developers to mentor new programmers looking to become developers one day.

It'll take the form of a Software Developers' Guild - a sort of clearing house that helps talented new programmers find old hands who can provide "light-touch" guidance over the long-term (4-6 years).

I see it working along similar lines to what I've been doing with my "apprentice" Will Price (who's just finished his final exams for his CS degree, and has turned out pretty spiffy as a developer, too). I've been pairing with Will regularly for a couple of hours every fortnight or so, working on the skills formal education tends to leave out (using version control, test automation, TDD< refactoring, design principles and other practical aspects of code craft).

I've also been nudging him towards certain sources of information: books, blogs, conferences, and so forth, and generally giving him a steer on what he would find most useful to know as a software developer.

Reflecting on how it's gone, both Will and I feel it's been of immense value - and not just for Will. Mentoring someone new to this field has spurred me to learn new things, too (like Python, for example) and reinvigorated my enthusiasm for learning. So, after twelvety-stupid years as a developer, I feel renewed. And looking forward to doing it again.

The industry is also up on the deal by one potentially great developer.

My thinking of late has been that this could be a workable route to avoiding the Groundhog Day that our profession seems stuck in, where new developers have to go through the same long process of rediscovery, with all the false leads and dead ends I wasted years on.

And so, this year, I tentatively begin the process of trying to scale this approach up. You can find out a bit more by visiting the Software Developers' Guild holding page. And, maybe, you'd be interested in becoming a mentor?

I'm looking for experienced developers who've "been around the block at least twice" ( call it my Rule of Two), and who'd be willing and able to provide a similar kind of light-touch guidance to someone at university, or from a code club, or returning to work after raising children or caring for a relative, or retraining for a career change, etc.

Could that be you?




May 16, 2017

Learn TDD with Codemanship

My Obligatory Annual Rant About People Who Warn That You Can Take Quality Too Far Like It's An Actual Thing That Happens To Dev Teams

If you teach developers TDD, you can guarantee to bump into people who'll warn you of the dangers of taking quality too far (dun-dun-duuuuuuun!)

"We don't write the tests first because it protects us from over-testing our code", said one person recently. Ah, yes. Over-testing. A common problem in software.

"You need to be careful not to refactor your code too much", said another. And many's the time I've looked at code and thought "This program is just too easy to understand!"

I can't help recalling the time a UK software company, whose main product had literally thousands of open bugs, hired a VP of Quality and sent him around the dev teams warning them that "perfection is the enemy of good enough". Because that was their problem; the software was just too good.

It seems to still pervade our industry's culture, this idea that quality is the enemy of getting things done, despite mountains of very credible evidence that - in the vast majority of cases - the reverse is true. Most dev teams would deliver sooner if they delivered better software. Not aiming for perfection is the enemy of getting shit done more accurately sums up the relationship between quality and productivity in our line of work.

That's not to say that there aren't any teams who have ever taken it too far. In safety-critical software, the costs ramp up very quickly for very modest improvements in reliability. But the fact is that 99.9% of teams are so far away from this asymptote that, from where they're standing, good enough and too good are essentially the same destination.

Worry about wasting time on silly misunderstandings about the requirements. Worry about wasting time fixing avoidable coding errors. Worry about wasting time trying to hack your way through incomprehensible spaghetti code to make changes. Worry about wasting your time doing the same repeatable tasks manually over and over again.

But you very probably needn't worry about over-testing your code. Or about doing too much refactoring. Or about making the software too good. You're almost certainly not in any immediate danger of that.







May 9, 2017

Learn TDD with Codemanship

What Makes a Software Developer? The Rule of Two

I've been thinking a lot recently about what might qualify someone as a "software developer". For sure, it's not just someone who can code. (Any more than a builder is just someone who can lay bricks.)

One rule of thumb I've used with some success over the years is a rule of two: a software developer, in my experience, is someone who has practical hands-on skills in at least two of everything.

* 2 different programming paradigms (e.g., structured & OO)
* 2 different technology stacks (e.g., LAMP and .NET)
* 2 different kinds of application (e.g., desktop and mobile)
* 2 different problem domains (e.g., banking and medicine)
* 2 different approaches to development (e.g., Extreme Programming & RUP)

Essentially, someone who's been around the block at least twice in their careers.

The reason why I think this matters is that folk tend to need to see multiple examples of something before they can start to draw some key underlying insights. If you've only ever done BDD, you may not be aware that almost all approaches to requirements specification are example- or scenario-driven. If you've only ever worked in, say, Java, you may miss the fact that encapsulation isn't exclusively an OO concept. (Yes, you can have loosely coupled modules in Pascal, C, etc, too).

I'd also be interested in the responsibilities a developer has taken on in their careers. I've been a programmer, a tech lead, an architect, a requirements analyst, a methodologist, a strategist, a coach, a conference speaker, a conference organiser, an author, a business owner, and a trainer in my twelvety five years in this career. Wearing multiple hats - like working in multiple languages - can bring insights that decades working exclusively at the code face would probably miss.

So now, as my attentions turn to focus on the whole question of long-term mentoring for would-be software developers, the >rule of two may well be a key part of the process of identifying who might make good mentors, as well as potentially provide a roadmap for mentoring itself. Essentially, we'd be looking to guide rookies at least twice around the block, allowing them a chance to build those insights for themselves.


April 17, 2017

Learn TDD with Codemanship

Do It Anyway

In my previous post, I suggested that developers take the necessary technical authority that managers are often unwilling to give.

If I could summarise my approach to software development - my "method", if you could call it that - it would be Do It AnywayTM.

An example that recently came up in a Twitter conversation about out-of-hours support - something I have mixed feelings about - was how temporary fixes applied at 2am to patch a broken system up often end up being permanent, because the temptation's too great for managers to assign the fixer to seemingly more valuable work the next day.

Think of out-of-hours fixes as being like battlefield surgery. The immediate aim is to stop the patient from dying. The patient is then transported to a proper hospital for proper treatment. If the patient's intestines are being held in with sticky tape, that is not a lasting fix.

We've all seen what happens when the code fills up with quick'n'dirty fixes. It becomes less reliable and less maintainable. The cumulative effect increases failures in production, creates a barrier to useful change, and hastens the system's demise considerably.

My pithy - but entirely serious - advice in that situation is Do It AnywayTM.

There are, of course, obligations implied when we Do It AnywayTM. What we're doing must be in the best interests of stakeholders. Do It AnywayTM is not a Get Out Jail Free card for any decision you might want to justify. We are making informed decisions on their behalf. And then doing what needs to be done. Y'know. Like professionals.

And this is where the rubber meets the road; if managers and customers don't trust us to make good decisions on their behalf, they'll try to stop us making decisions. It's a perfectly natural response. And to some extent we brought it on ourselves - as a profession - through decades of being a bit, well, difficult. We don't always do things in the customer's interests. Sometimes - gasp - we do stuff because it benefits us (e.g., adopting a fashionable technology), or because it's all we know to do (e.g., not writing automated tests because we don't know how), or just because it's the new cool thing (and we love new cool things!)

If we can learn to curb our excesses and focus more on the customer's problems instead of our solutions, then maybe managers and customers can learn to trust us to make technical decisions like whether or not a hot fix needs to be done properly later.




April 15, 2017

Learn TDD with Codemanship

IT's Original Sin: Separating Authority & Expertise

I'm recalling a contract I did a few years ago, where I was leading a new team on an XML publishing sort of thing. The company I was working for had been started by two entrepreneurs who had zero experience of the software industry. Which is fine, if you can hire experts who have the necessary experience.

On our little team, things were generally good, except for one fly in the ointment. The guy they'd trained up in this specific database technology we were using had his own ideas about building the whole thing in XQuery, and refused to go along with any technical decision made by the team.

Without his specific skillset, we couldn't deliver anything, and so he had the team over a barrel. It should have been easily fixed, though. I just had to go to the bosses, and get an executive decision. Case closed.

Except the bosses didn't know whether to believe me or believe him, because they knew nothing about what we were trying to do. And they were unwilling to concede authority to the team to make the decisions.

This is a common anti-pattern in the way organisations are run, and it seems to be getting worse. Our whole society now seems to be organised in a way that separates decision-making authority from expertise. Indeed, the more authority someone has, the less they tend to understand the ramifications of the decisions they're making.

In Britain, this is partly - I think - down to an historical belief in a "leadership class". Leaders go to certain good (fee-paying) schools, they get classical educations that focus on ancient languages, history, literature etc, and they study purely academic non-technical subjects at university like Politics or History. They're prepared for the burden of command by their upbringing - "character building" - rather than their actual education or training. They're not actually qualified to do anything. They're not scientists, or doctors, or nurses, or engineers, or designers, or programmers, or builders, or anything drearily practical like that. They're leaders.

These are the people who tend to end up in the boardrooms of Britain's biggest companies. These are the people who end up in charge of government departments. These are the people who are in charge of TV & radio.

And hence we get someone making the big decisions about healthcare who knows nothing about medicine or about running hospitals or ambulance services. And we get someone in charge of all the schools who knows nothing about teaching or running a school. And we get someone in charge of a major software company whose last job was being in charge of a soft drinks company. And so on.

Again, this is fine, if they leave the technical decisions to the technical experts. And that's where it all falls down, of course. They don't.

The guy in charge of the NHS insists on telling doctors and nurses how they should do their jobs. The woman in charge of UK schools insists on overriding the expertise of teachers. The guy in charge of a major software company refuses to listen to the engineers about the need for automated testing. And so on.

This is the Dunning-Kruger effect writ large. CEOs and government ministers are brimming with the overconfidence of someone who doesn't know that they don't know.

Recently, I got into a Twitter conversation with someone attending the launch of the TechNation report here in the UK. It was all about digital strategy, and I had naively asked if there were any software developers at the event. His response was "Why would we want software developers involved in digital strategy?" As far as he was concerned, it was non of our godammed business.

I joked that it was like having an event called "HealthNation" and not inviting any doctors, or "SchoolNation" and not inviting any teachers. At which point, doctors and teachers started telling me that this has in actual fact happened, and happens often.

The consequences for everyone when you separate authority and expertise can be severe. If leaders can't learn humility and leave the technical decisions to the technical experts - if that authority won't be willingly given - then authority must be taken. The easiest way - for the people who do the actual work and make the wheels turn - is to simply not ask for permission. That was our first mistake.





March 22, 2017

Learn TDD with Codemanship

Digital Strategy: Why Are Software Developers Excluded From The Conversation?

I'm running another Twitter poll - yes, me and my polls! - spurred on by a conversation I had with a non-technical digital expert (not sure how you can be a non-technical digital expert, but bear with me) in which I asked if there were any software developers attending the government's TechNation report launch today.




This has been a running bugbear for me; the apparent unwillingness to include the people who create the tech in discussions about creating tech. Imagine a 'HealthNation' event where doctors weren't invited...

The response spoke volumes about how our profession is viewed by the managers, marketers, recruiters, politicians and other folk sticking their oars into our industry. Basically, strategy is non of our beeswax. We just write the code. Other geniuses come up with the ideas and make all the important stuff happen.

I don't think we're alone in this predicament. Teachers tell me that there are many events about education strategy where you'll struggle to find an actual educator. Doctors tell me likewise that they're often excluded from the discussion about healthcare. Professionals are just there to do as we're told, it seems. Often by people with no in-depth understanding of what it is they're telling us to do.

This particular person asserted that software development isn't really that important to the economy. This flies in the face of newspaper story after newspaper story about just how critical it is to the functioning of our modern economy. The very same people who see no reason to include developers in the debate also tell us that in decades to come, all businesses will be digital businesses.

So which is it? Is digital technology - that's computers and software to you and me - now so central to modern life that our profession is as critical today as masons were in medieval times? Or can any fool 'code' software, and what's really needed is better PR people?

What's clear is that highly skilled professions like software development - and teaching, and medicine - have had their status undermined to the point where nobody cares what the practitioner thinks any more. Except other practitioners, perhaps.

This runs hand-in-hand with a gradual erosion in real terms of earnings. A developer today, on average, earns 25% less then she did 10 years ago. This trend plains against the grain of the "skills crisis" narrative, and more accurately portrays the real picture where developers are seen as cogs in the machine.

If we're not careful, and this trend continues, software development could become such a low-status profession in the UK that the smartest people will avoid it. This, coupled with a likely brain drain after Brexit, will have the reverse effect to what initiatives like TechNation are aiming for. Despite managers and marketers seeing no great value in software developers, where the rubber meets the road, and some software has to be created, we need good ones. Banks need them. Supermarkets need them. The NHS needs them. The Ministry of Defence needs them. Society needs them.

But I'm not sure they're going about the right way of getting them. Certainly, ignoring the 400,000 people in the UK who currently do it doesn't send the best message to smart young people who might be considering it. They could be more attracted to working in tech marketing, or for a VC firm, or in the Dept of Trade & Industry formulating tech policy.

But if we lack the people to actually make the technology work, what will they be marketing, funding and formulating policy about? They'd be a record industry without any music.

Now, that's not to say that marketing and funding and government policy don't matter. It's all important. But if it's all important, why are the people who really make the technology excluded from the conversation?