Andy, the release manager at my current client, asked, “How can I get the teams to follow a consistent process where readying the release for deployment is concerned? We have different version control systems, different build processes… how do I make them behave in the same way?”
Ask for consistent outputs, not consistent processes
In a waterfall-ish world, teams hand over the artifacts of their processes to other teams, who take them away and use them. Each team rarely has insight into what the other teams get up to with their artifacts. The team will produce the artifacts whether they’re needed or not, because they’re part of the process. Release management’s artifact has usually consisted of a document detailing the steps to check out, build and deploy an application, signed off by a gatekeeper who may or may not be familiar with the process itself.
In our lean world, the processes which the team goes through are defined by the team themselves; adapted and changed as the team continually improve. As part of that continual improvement the team may discover new and different ways to collaborate with their stakeholders, including the incidental stakeholders, who may not be paying for the project or using it, but who care nontheless.
Andy is one of these incidental stakeholders.
“If you’re a stakeholder,” I suggest, “you get to put your requirements to the team as well. Ask them for the thing you need. If you need consistency, tell them what consistency looks like. Get them to put the artifacts in a place where you can find them, together with a script that allows you to deploy. Your team are the ones with expertise in deployment, so they might usefully collaborate with the development teams to produce those scripts.” We talk a little about using the Feature Injection template for technical stories, continuous integration, and how the build might play into deployment. “Imagine if you could then just press a button and have those artifacts deploy themselves. How much would that benefit the QAs?”
“Right! And we’d get round the problem we have now, where we don’t deploy the services together with the applications until System Test, where of course they don’t work together.”
“They still won’t work together,” I reply. “All the mistakes in other processes also happen in Lean and Agile; the only difference is that we expect them. We don’t hope they won’t happen – instead, we know they will. We make it safe to fail, instead of fail-safe. This time, we’ll find out while the mistakes are still small, and after that every fix we need will also be small. We’ll also find the mistakes close to the place where they’re created, and the knowledge of how to fix them will be fresh.” We talk about Work In Progress as a liability, and move from there onto the similarities between Lean software development and Lean manufacturing.
Software development is not a production line
A large number of the metaphors of Lean manufacturing which we bring into software development have to do with the production line – that conveyor belt with the “stop the line” Jidoka handles on which the cars are built. Unfortunately, software development isn’t like building cars. If we find ourselves building the same software over and over again, perhaps configured slightly differently depending on the customer, then we’re not creating anything new and we should just use the same software we designed before, or buy something that someone else wrote.
Software development is about creating new things. It’s more like the product development shop; designing new cars, instead of building the same models over and over again. Ideally, it’s about trying out risky things – things which no one has done before. When we try new things, they sometimes don’t work.
“Yes,” Andy comments. “I’d love us to learn better from our mistakes.”
“They’re not really mistakes,” I hazard. “If we’re doing things that nobody has done before, then of course some of them won’t work. If someone is making mistakes it’s either because they’re human – and that isn’t going to change in a hurry – or because the system is set up in such a way that it was always going to happen. We can build safety in to catch the human mistakes. If we blame people for getting things wrong then they have a tendency to hide their mistakes. Instead, we want them to try things out. We want them to learn.”
“We should focus on the good side of making mistakes,” Andy muses.
“Even the act of making mistakes might be considered a good thing. We’re trying things out and learning from them; that’s innovation at work. If we change our language, people behave differently. We can focus on exploring ideas instead of avoiding risk.”
Integration and deployment is a production line
Once we’ve developed some software, we want to get it out into the world. This is where the metaphors of the Lean manufacturing production line come in – Jidoka, or the act of “stopping the line” to fix any problems with it; the button-click from a tester or release manager that signals the need for a fresh deployment, just like Kanban; delivery to the end-customer which provides the feedback to the team.
“Right now, we’ve started to introduce good practices into the team but we’re still not doing automated deployment,” I explain. “That’s like having a high-tech development shop designing the latest cars, then putting them together by hand, using techniques from 1900 – filing this screw here, hammering this panel to fit into place, every time a different set of problems to adapt to.”
“You’re right. I hadn’t thought of it like that,” Andy smiled. “This is going to make things a lot easier.”
Automation doesn’t make it easier
Automation introduces its own set of problems. In my opinion, these are much more interesting problems than, “How do we get our software to work in production?” Instead, we have, “How do we configure our webservers remotely? Do we want virtual servers? How big a sample of production data do we need for UAT? How can we get faster feedback from the build? Can we create a preview site?”
As well as freeing people up to answer these questions, automation allows the release team – rapidly becoming more of a community than a team, and sharing their expertise as they go – to collaborate with the developers, creating software that’s easier to build and deploy, or even coming up with new build tools. The ease of deployment may not increase, but the quality and consistency will.
There are plenty of different types of conveyor belt available – my favourite software conveyor belt right now is Hudson – and they can be configured to twist and turn the different artifacts in all the usual ways. Giving the developers a miniature version – maybe with a smaller data set, or enough to just build their engine or gearbox or whatever module they’re working on – can help to ensure that the software is buildable.
Expect, however, that if you’re doing tricky things with your software that require a unique approach to building it, you may have to spend time designing and building new production line tools.
That’s all right, because they’re just software too.
Pat Kua’s running a Dreyfus modelling session at Agile 2009 that you should attend if you’re there and remotely interested in how people learn.
Contrary to what it says in the printed program, I won’t be helping to run it. I would have loved to, and unfortunately managed to overcommit some time between the decision to add me to the program and asking if I was available. I think we’ll try that the other way round next time…
So, apologies if you were hoping to go to that session to hear me speak. Go anyway. Pat’s coach-coaching has made a significant difference to my skills, he’s a clear and imaginative speaker, and the outline looks like educational fun, as do the results of the last time he ran this.
I’ve just been reading Alan Skorkin’s and Mark Needham’s posts on the Dreyfus Model.
It’s curious to me that Alan says, “it does nothing to help us build experts from the more junior people on the team!” and Mark says “There seems to be potentially some conflict here with Marcus Buckingham’s idea of focusing on your strengths if our strengths aren’t aligned with the most important skills for software development.”
I’ve not grown experts – yet – but I believe I’ve managed to set people firmly on that path, and used the Dreyfus model to do it. Certainly, I’ve changed teams from novice and beginner up through to knowledgeable and competent, using the models as a roadmap. If it’s useful, I’d like to share some of the ways in which I apply the model which may be different to Alan and Mark’s techniques.
Junior people aren’t novices, and senior people aren’t competent.
Certainly not in everything, anyway. A junior person who’s joined a team as a software developer has probably got a great deal of knowledge about some facet of software development. Their best skill may not be in a technical practice! They may be fantastic facilitators, speed readers, domain experts, etc.
Equally, a senior developer requires different skills to a junior developer – and most of those extra skills aren’t technical. They need patience, the ability to pass on their knowledge, communication skills to find out about the big picture, time management skills, skills in giving feedback constructively (and receiving it!), and even a few skills which sit under my “coaching” models. A senior developer who’s technically brilliant may still be lousy at bringing that brilliance to a team. Mark pointed out, “It’s ok to be a novice at some things”. I’d go further, and say that this is the norm. One of my big weaknesses is estimation – I hate doing it, and am usually an outlier with no real reason – but at least I know, and can defer to my more skilled team-mates.
If we find the practices in which people are already competent we can add them to the model, giving them at least one point which allows them to say, “In this, I am successful.”
I’ve never coached anyone who didn’t turn out to be successful in at least one practice, so I haven’t needed to do this yet. People who aren’t successful in some respect tend not to get hired for that role.
Model with examples.
Think of the ways in which novices learn. Driving a car is a good example (of examples) for this. I am a novice; I use the gear, use the brake, use the steering wheel. I am taught the steps of moving off, parallel parking, emergency braking. I need more practice before I can even be a beginner.
As a beginner, I’ll be able to park without hitting the kerb, slow down gently at junctions, steer intuitively, drive at (legal) speed, etc. – but I won’t be able to do all of these, and only some of them will be intuitive.
As a competent driver, experts will agree that I am safe to drive independently.
As a knowledgeable driver, I will be able to have a new car. I will be less likely to have accidents. I will slow down near schools – not because I know I should, but because I instinctively recognise it as a dangerous area to be driving fast in. I will spot the idiot undertaking me on the motorway, and let him go past before pulling in. I will be at one with my car.
As an expert I will perform stunts, drive into the skid, evaluate different cars, judge others on their driving (impartially and accurately!), and do crazy things that most people don’t get to do, even if they are competent (and most people think they’re above average, even when they’ve forgotten most of the practices that allowed the expert to judge them as being successful – this is largely true of all skills, not just driving).
I can’t drive – I really am a novice. I can only model the skill of driving because I know a lot of drivers. See the stuff about GROW further down for how I’d go about coaching someone to learn to drive.
Play on people’s strengths.
There’s a reason you can’t grow a novice into an expert using the Dreyfus model. By the time we hit our professional environment, we’ve usually become at least competent in the practices in which we have the greatest interest – even if that’s nothing more than “I really like solving problems” or “I get computers”. I’ve just finished Malcolm Gladwell’s “Outliers” and found out about the 10,000 hour rule. I’m pretty sure I had 10,000 hours of problem solving under my belt by the time I graduated. Most developers are expert problem solvers (as long as the problems remain logical). Most of us are also competent programmers for small programs.
If you can find the skills in which people are already successful, you can use those to identify, and grow, related skills.
Someone who has taken up a practice but shown no real interest in progressing to the point of being independently successful is probably never going to be an expert. However, they may well become independently successful. Aim realistically.
After that, play on people’s strengths. I give numbers to the Dreyfus models, and let people sit halfway between them, so for me the most interesting numbers are 2.5 and 3.5 – beginning to experiencing some level of success, or successful and wanting more. These are the quick wins; the places in which people can grow swiftly from beginner to competent to knowledgeable practitioner.
I can tell .5s because they’re doing some of the things I see at the next level, but not all of them; usually in one context but not another. So, for instance, I met a manager today who’s great at motivating his people to deliver, but has never thought of motivating them to learn and improve themselves. I have no doubt that now he’s aware it’s important in a Lean environment, he’ll go ahead and make the right space and noise for them to do it, and get better at it over the next few months.
The numbers I love most to see are 4s – the knowledgeable practitioner. These are the people I use to spread expertise in the team. I know they’re not experts, but by the time they’ve spent a few years indulging in conversations and answering the questions for themselves as well as other people, they might well be.
Avoid the word “competent”.
You and I know what that word means, because we’re familiar with the Dreyfus model, and probably the model of conscious competence too. However, to someone who’s not into learning models, the word “competent” together with any insinuation of “you’re not” correlates with the words “incompetent” and “fired”. Making people scared tends to stop them from admitting to weaknesses and mistakes, which tends to stop them learning, and the word “competent” is scary.
I’ve replaced the word “competent” with “practitioner” in my models, and I tend to talk about being “independently successful”. That is, even as a novice or a beginner, you can be successful on a team where someone is around to catch your occasional mistakes or give you guidance to avoid them.
This helps coachees get away from worrying about addressing their weaknesses – which will develop with practice anyway, and with help from the rest of the team – and towards acknowledging their strengths.
Equally, concentrate on the people in the team who are ready to grow. They’ll help the others.
GROW them.
GROW stands for Goal, Reality, Options, Way Forward. I get the coachee to pick a couple of skills in which they want to improve (they’re rarely novice skills, which is fine by me). The conversations usually go something like this:
“So, you’re a 2.5 and you’d like to be a 3 – independently successful. Can you see yourself doing the things written here? Which ones do you think you might have problems with? Is it a matter of not knowing, or not understanding? Would you simply like to be more confident? Would you like to know which books cover this subject? Can you think of anyone else who’s better at this than you, who you could talk to and find out how they do it? Do you think it just needs more practice?”
We establish a goal, which means that the coachee visualises what it would be like if they were at the next level in that practice – how they might behave differently, or how they’ve seen other people behave that they’d like to emulate (look at NLP’s “well-formed outcomes” for really great ways of knowing whether you’ve achieved this). We then look at different options and resources for getting from the level they’re at, to the level at which they want to be. Then we agree to try something out, and revisit it a week or two later to see how it went.
Interestingly, the act of visualising the next level sometimes causes people to take on the different behaviour, which helps coachees to learn what happens when they try the new practices. If maintained for long enough it becomes a conscious habit; otherwise you’ll see that person revert under pressure. The behaviour of a manager under pressure tells me a lot about more about their ability to motivate people and provide realistic targets than their behaviour when things are going well! I also discuss with the coachees whether they’d revert or not; so far they’ve been honest enough to admit it if it’s true, and then we can find more appropriate options.
Look for years, not months.
Expertise does not happen overnight. There is no quick way to grow a novice into an expert (and you probably want to concentrate on a different, non-novice practice anyway). The 10,000 hour rule still applies – but we’re talking about experts, not practitioners. It’s perfectly OK for someone to be a well-rounded individual! On my own measurements of a Dreyfus Developer, the only skill I’m an expert in is BDD (and therefore its subset of TDD) – and only because I’ve spent just about every lunchtime, weekend and hour in the bar talking about it, practicing and teaching others for the last five years.
And I’m still learning about the practices which play into BDD, and how much fun you can have with it, and how it’s done in Ruby, and how it’s still evolving. Even expert skills can be broadened.
Applying the Dreyfus model is a skill.
Here are the “Applying Learning Models” models from my “Coaching Competencies”. They’re probably not accurate above the practitioner level, because I don’t really have access to any experts in this. I’m not an expert myself – just successful (and re-reading this post back to myself tells me I’ve learnt more since writing them; maybe I’m more than just successful now).
If you know better, please help me become an expert!
- Novice:
- Knows what a successful user of a skill looks like
- Encourages individuals to become practitioners
- Experienced Beginner:
- Can articulate the difference between someone following novice steps and a successful practitioner
- Has an awareness of the kind of practices which might lie beyond practitioner level
- Understands that it is not always necessary to address a weakness in a skill or practice
- Encourages individuals to identify and play on their strengths
- Practitioner:
- Can look at a practitioner in a skill and identify steps which are suitable for novices
- Can draw out past difficulties from practitioners and identify for novices who are gaining skill
- Can draw out current issues from practitioners and identify knowledgeable and expert practices which address those issues
- Can help individuals to measure their progress accurately by providing observed examples of their practices or antipatterns
- Targets the expertise of an audience appropriately
- Knowledgeable:
- Can examine an individual’s skill level and help him identify paths forward to the next level of skill
- Fluidly tailors presentations or workshops to the expertise of the audience
- In an audience of mixed expertise, calls out the level of expertise being addressed at any time
- Can articulate the dangers of targeting novice practices as indicators of performance
- Expert:
- In an audience of mixed expertise, provides a route map that celebrates the ongoing journeys of novices and beginners whilst providing practitioners and above with a route forward
- Can map different learning models to each other.
Grow expertise using experts.
I’ve never taken anyone from novice to expert, but I’ve certainly coached them from experienced beginners to knowledgeable practitioners, and from competent practitioners to expert. I’m particularly proud of Andy and Antony’s expertise in BDD, Szczepan’s creation of Mockito, and certain team-leaders and technical experts who’ve gained coaching skills.
The thing is, I didn’t do all the work – they did it themselves. All I did was make a couple of remarks, point them at some resources, and allow others to do the same. And they weren’t exactly novices to start with. So, if you want to grow expertise in a team – use other people too. Be a coach, not a trainer.
(Thanks to Andy and Antony for teaching me the power of collaboration, Szczepan for prompting me to rewrite JBehave, and the team-leaders and technical experts for passing on leadership and technical expertise…. amongst other things. I’ve come to realise that successful coaching is rarely a one-way transaction, and often just a straight swap.)
Dan North and I will be heading up a free introductory BDD talk at Skills Matter’s headquarters in Clerkenwell near Farringdon, London, next Monday. Drinks will follow.
I like working with Skills Matter because they genuinely believe in, and invest in, the communities that surround the subjects they teach. This is part of their ongoing contribution to the BDD sphere; further free talks are scheduled for the rest of the year. I hope this community is as long-lasting as XtC!
If you want to pay them back, come to my BDD developer workshop in October!
When I first found out about BDD, way back in 2004, I remember TDD being rather like an ant looking for a flower on a tree, and telling all the other ants back at the nest on the ground about the route.
As the ant, I know roughly where I’m going. Sometimes I can even see the flower! But I keep going down dead-ends and having to backtrack. When I finally find the route and try to talk to the other ants about it, it’s hard to remember the direct path.
The mental map I had of my code looked rather like the path I’d taken as the ant. It was never completely clean. I had no flash of clarity; no sense of “This is the right way!”
Contrast that to the feeling I got when I started using the language of BDD (this was just before I realised that BDD also allows me to do outside-in development.)
If I can fly, I can move outside the tree. I can see the flower, then crawl from the flower to the twig, to the branch, to the trunk and down to the nest. The path is clear. I can tell the other ants exactly where I started, and how I reached them. Life is simple and beautiful. I can see how other ants might have become confused. I can see the other routes that might have side-tracked me. I just don’t have to go down them any more.
BDD gives me wings.
I’ve found myself repeating this a few times lately, so maybe it will help some people out there.
In BDD, we don’t design using mocks.
We design by thinking about context, responsibility, collaboration and delegation, then we use mocks to express that (or stubs, in the case of context).
If we can find a different word to replace mock, stub, test-double, test-spy, etc., we probably should. In the spirit of BDD’s NLP roots, it might help us think differently. There may be more than one word for different uses. Any suggestions?
Tyburn, the little GUI harness for helping you Swing more easily, has had a few changes:
- Slow mode now added, so you can use it to show your scenarios being run (great for BDD presentations or working out what’s actually causing that bug)
- The Ascii Grid DSL converter which I’ve used for Tetris and the Game of Life for years has been added
- You can now specify the timeout for finding an open window
- You can ask the control if it’s got the window open (makes it easier to close all windows in a tear-down).
While I’m coding, I usually have a bunch of very helpful pixies hanging around my desk. (They’re Dan’s pixies really, since he thought of them first; I’m just borrowing them.)
The pixies are bored, and just waiting for a job to do. So, when I’m coding a class, they look out for opportunities to help out that class. When I’m coding the Game of Life, for instance, I write a Gui class that lets me toggle the cells on the grid. Then I have to work out what happens when I toggle the cells.
I could do it in the same class – in the gui – but fortunately the pixies step in to prevent me making these poor design decisions. “Oh, I’ll do that for you!” one of the pixies calls out. (They usually start with this phrase, and they’re all called Thistle.)
“Thanks, Thistle! Do you know what you’re doing?”
“Um, not really. What’s toggling a cell? Why’s that valuable? What is it you want me to do for you again?”
“I need you to handle the cell living and dying when I toggle it.”
“Oh, okay!” Thistle says. “I don’t like the ‘and’ word so much, though. It makes me feel like I’m doing two things at once. What do you call that? The living and dying thing?”
“Hm.” I think about it while the pixie taps his foot impatiently. “I’d call it a lifespan, maybe. Can you handle the cell lifespan for me? Just let me toggle the cells. I also need you to tell any observers that there have been some changes to the cells, and give them a way of finding out where those changes are. I think they’ve already got an idea of what they want there.”
“Really? Both things?”
“Well, there’s no point doing one if you don’t do the other. It’s all part of the same role.”
“If that’s what’s valuable to you then I’ll do it,” he says. “Just pretend I’m there for the moment; I’ll be back when you need me.”
“Fine,” I say. So I use a mock pixie in place of the real one. I create an interface which does what the pixie’s going to do: IHandleCellLifespans.
(See, it’s an interface that starts with “I”, and it represents a role that the pixie is playing for me. This is a role-based, anthropomorphized interface.)
So, now we have code which compiles. Of course, the real code in the Gui is null, or maybe a null object pattern – I might create something like IHandleCellLifespans.KILLING_THEM_ALL if I’m feeling particularly mean. But that’s all right, because Thistle the pixie will step in when it’s time.
So, I run the code. I’ve usually written an automated scenario. It doesn’t matter whether I run the scenario or step through the game manually; both result in the same thing happening, or not happening – no matter where I click the mouse, no cells appear. Pixies are notoriously unreliable.
Since I can’t rely on the pixies, I inject a new class to handle the dependency instead. I decide to call it the Engine, for the moment, and I write an example of how to use it and what it should do for me.
The next step is the Next button. I think about how this would work in the Engine, and start writing some code to show how the Engine needs to behave. I’ll need to calculate the number of neighbours, and apply the rules accordingly.
One of the pixies pipes up, “Oh, I’ll do the neighbours!” and another one says, “Oh, I’ll handle the rules!”
“Fantastic!” I’m so trusting; I always forget what these pixies are really like when it comes to getting the work done.
“If I’m going to count the neighbours,” Thistle says, “I’ll need some information about where I’m counting from, and what’s around me.”
“Ah, I can get the information from the cell itself,” I say.
“No, don’t do that. It’s fine where it is; I’ll just sit inside the cell and do it from there. Can you give me something that lets me know where the other cells around me are? Then I can do the work for you.”
“Sure,” I say, “the Engine knows where the life is. I’ll just give you access to the Engine and let it play that role for you.”
“Can’t I do it instead? I’m bored,” one of the other pixies asks. “Just give me the information from the engine, and let him talk to me instead.”
“Um, Okay.”
Of course, when I try to run it then I find out that all the pixies have mysteriously vanished, and I end up assigning the role to the Engine anyway, or one of its anonymous inner classes. Having it defined as a different role means that it’s easy to move this responsibility around. Maybe I’ll create a World to look after the cells, and let that do the job instead; the pixies certainly aren’t very helpful.
“What do you mean, we’re not very helpful?” Thistle says. “Look at your code. You haven’t written anything that isn’t needed by something else, so there’s less code to maintain. Because we jump in all the time to try and do jobs for you, every time you can assign a new responsibility to something else, you do – that’s the single responsibility principle in action; none of your classes are doing too much. And you can replace us with something else that does the job at any time – that’s the Liskov Substitution principle. The roles we perform are clearly named. It’s been easy to describe the behaviour of each class using mocks to stand in when we’re not there, and the examples are very readable. You can also use them to work out whether your code still works or not, by running them as tests.”
“Okay. I can’t see myself relying on you guys for bigger, enterprise stuff, though.”
“What do you mean?” Thistle looks offended. Oops.
“Well, let’s say that I’ve got a shop, and I need the tills to talk to stock control.”
“Controlling stock? Oh, I’ll do that!” one of the pixies announces excitedly.
“What, all on your own?”
“Well, I’ll probably delegate it to a team, but that’s my responsibility – you don’t need to worry about it. I’ll be there when you need me. Just pretend I’m there for now. How would you like to find me? What kind of stuff are you going to send to me, and what do I need to do with it? What would you like back?”
So I start with something simple – a URL that I’ll use to find Thistle the pixie, some domain objects that I want to send him, and some objects that I’d like back in return. We talk about how to get the information across, whether some of the tills might provide different stock information, how to talk to the claims department about the quality of the goods we’re selling, and whether I’ll be okay if the claims he gives me have more information than I need.
“Hold on,” I say. “You’ve got me playing this game now. I’m not a Claims Department. I’m not going to do the job myself. I’ve got a home to go to!”
“Meh, never mind,” Thistle replies. “I’ll be sitting with this team over here, coding the stock control. We’ll just pretend you’re doing the job; we’ll mock you out for now.”
“How will I know that I’m doing the job correctly?”
“We’ll have to talk to each other occasionally. Is that going to be hard? We’ll write some scenarios over in our team that describe how we’re going to use you.”
“What if I make a mistake?”
“Do you know what mistakes you’re going to make already?”
“No,” I confess. “I’m sure there will be some, though.”
“When you make a mistake, we’ll deal with it at that point. Sound good?”
I think about it. I reckon I could write some code that pretends to be doing the job of the Claims Department and responds correctly to the way they’ve described how they’re going to use me – just for those examples – then I could go home and Thistle would never know. I knock up a quick stub and slip it into the stock control team’s scenarios, then I disappear too, just like the pixies. I figure I’ll start coding a real Claims Department that does a more robust job tomorrow.
When I get back the next morning, all the pixies performing the role of Stock Control have been replaced with code too. The Stock Control team claim that they’ve never even seen them.
I corner Thistle again. “You’re really not very helpful, are you?”
Thistle looks sulky. “Of course we are! Look at your architecture. You’ve got simple messages going back and forth. Your code is very tolerant of extra information, as is the code on this side. You’ve got lovely RESTful URLs, because you were thinking about how you’d like to find us, instead of us providing you with some weird mechanism that doesn’t match exactly what you wanted. We’ve got clean interfaces and APIs. There are no extra columns in your database, because you only replaced exactly what we said we’d do in the first place. You’ve got scenarios to describe how we work together, and at a unit level examples to describe how you’re delegating responsibility to the other pixies. It’s a lovely, maintainable system with a fairly flat cost of change. Isn’t that what you wanted?”
I nod thoughtfully. “I think it would have been easier for me to just write the code instead of going through you all the time.”
“Ah,” says Thistle, “but then you’d have code that was easy to write, instead of code that’s easy to use.”
I think about how they made me fill in the role of the Claims Department. “You never did any of the work, though! I could have done that job myself; put myself in each of those roles and then replaced myself with real code. That would have let me create consumer-driven interfaces just as easily as using you.”
Thistle shrugs. “If that’s what works for you, sure.”
“Won’t people think I’m a bit mad? If I start talking about how I’m personally going to use a particular class, or how I’m offering to do a job for another?”
Thistle looks at me with raised eyebrows, then gestures at all the other pixies clustered around my desk.
“I think it’s a little late to be worrying about that now,” he says.
Pascal Van Cauwenberghe has written a great post on estimating business value, tying it into a feature-injection style template. I particularly like the idea of calculating business velocity, and showing value earned over cost on a visible chart.
Even though we know that cost accounting isn’t useful without looking at ROI, many companies still have this focus (how many people have had problems getting hold of sharpies because they’re "too expensive"? Coloured post-its? Free coffee?)
Perhaps by making the return on investment over time apparent to everyone, we can motivate the team, show the value we’re earning and gain the trust of the business at the same time.
As an aside, I remember one client where the deadline was very tight, but nobody wanted to work overtime or weekends. Our PM asked us if there was anything we’d like to have which would help us work more effectively. We asked for – and got – fresh fruit every day. The difference in our work – both the amount and quality – was noticeable! (We already felt very well respected, so I discount the placebo effect here).
It’s amazing how much difference a few pounds of expense can make.
On an aside, some people have asked me why I’ve chosen to set up my services site as a hard-coded website with server-side includes, instead of using another Wordpress blog or something similar. I did it because:
- It was the quickest way I could think of to get a website out with a reasonable amount of content
- I wanted to be able to get the style right (or at least usable) before I had to wrap it around Wordpress
- I had no idea what I was going to put in the website when I started.
Having said that, it’s now annoying me. There’s enough up there that the next stage is to, um, move it to a customised Wordpress site (it should look exactly the same, but be easier for me to administer).
I did learn a lot about CSS, Mercurial over SSH from Windows, and Apache SSI configuration while I was playing with this. It will be much easier for me to set up the Wordpress site, now I know what I don’t want on it and what I need for the styling to work. And I didn’t need a Wordpress site when I started. YAGNI wins again.
Comments