The Software Development Compromise

I've heard a lot of talk of compromise in our company lately, and the folk talking about it are absolutely right: we have to make a compromise between creating working software to sell and maintaining our codebase. We could spend years cleaning up, re-factoring and polishing what we have, but the reality is that new releases and completely new products have to be created at the same time, or the company has nothing to sell, we make less money and have to shed a load of staff, developers included.

However, I've heard little talk of how and when we make this compromise. What makes for a healthy compromise and what makes for a damaging one? Here are my thoughts on this, and they are simple.

When should we compromise?
We should compromise at the beginning of a project, when we have choices, rather than have a compromise forced upon us by circumstance in the later stages.

How should we compromise?
Actively and consciously. Again, it's all too easy to become a victim of circumstance, and have choices forced upon us through our inaction.

Who should compromise?
Naturally, the compromise should be made by those who are affected, so the developers should be involved in making the choice, as well as those people that are making the business decision. The most important thing here is that developers and product marketing managers make this compromise together, rather than either party forcing the compromise onto the other by their actions. The two points above should help to achieve this.

Finally, we need to remember that if we (as developers) are excessively happy with the balance, then it's probably too much in our favour. Likewise, product managers should also be aware that an outcome that suits them too much is likely to be unhealthy also. As someone once famously said,

Compromise is a solution that neither party is happy with

Best Reads of 2009-2010

It may seem like an odd time to do it, but I have a look back at the last 12 months in August because that's when my birthday is. It's late September now, but I've been distracted with a heavily pregnant wife, followed (as it so often is) by the arrival of a new baby.

So, what's got me going over the last 12 months? Well, to start with, I managed to avoid the pain and waste of time of any real howlers over the last year, and was very grateful for one free book.

First up, The Toyota Way by Jeffrey Liker has been my whole-year top read and gets 5 stars. It's books like this that make me wonder if we're anywhere near the mark in software development, as they show such a huge gap between those companies that think they're Lean and the real Lean experts. This is a great "ground up" book for all sorts of people, as it talks extensively about the foundations of Lean: the company learning philosophy, and doesn't talk about Lean as a set of practices, rather a way of thinking that inevitably gives rise to the Toyota Production System best practices we know about: Just In Time, Kanban and so on.

Second, Don Norman's The Design of Everyday Things was an absolute pleasure to read: full of "of course!" and "yes, that's infuriating!" moments. Another 5 star read, recommended to developers, designers, analysts and testers. Although it focuses on physical objects, the immutable models it presents for the psychology of interacting with the world is such a simple template to apply to everything, software included. This book has changed the way I look at most things, not just the software I write and manage. Those niggles that you feel when using something unsatisfactory will be made concrete and understandable once you've read this. Even better, you'll find yourself thinking of a better way, rather than just ranting "this is rubbish!", and let's face it, the best form of criticism is a better idea.

As I said earlier, I was fortunate to be granted a free read of Becoming Agile by Greg Smith and Ahmed Sidky, which I'm giving 5 stars. It was a desperate plea on this very blog that earned me a much appreciated free copy of this book: the title pretty clearly states that it is the answer to the question "Becoming Agile? But How Do I Stop Being Non-Agile?", so Greg Smith stepped in and helped me. I must insert the caveat that I may be biased toward this book, as its brand of pragmatism toward creating Agile processes seemed to favour the sorts of approaches I've tried already (such as in my post on Lean/Agile Project Control on Sharepoint), so this didn't challenge me to change, rather it helped me to see the full and natural path to a some of the goals I'm trying to achieve professionally. I think the most important things I learned from this book are about the process for changing an organisation over to a more Agile development cycle, not least to assess whether you are really ready! This is a great read for developers, project managers and managers alike, as it should help you to understand the benefits and risks of moving to Agile.

Although I believe W. Edwards Deming to be one of the most important figures in engineering and management, I've only given Out of the Crisis 4 1/2 stars. This is by no means intended to reflect on the quality of the content of the book (no pun intended), rather the style: a lifetime of experience and writings crammed into one volume is always going to struggle to come across as smooth flowing and succinct. The central themes of the book however are extremely cohesive and strongly put. I recently met someone who had the privilege of seeing Deming talk. He said that despite his advanced years, he stood at the lectern, fist-poundingly stern and passionate about the methods of management so desperately needed to drag the Western World forward. Read and be converted.

My final recommendation is Agile Testing by Lisa Crispin and Janet Gregory. I would have given this book 4 1/2 stars, but it's just way too long, so for that reason it only gets 4. However, despite the length, I would implore you to plough on, as nestling among the frequent repetition and often self-congratulatory side remarks, there is a lot of wisdom contained in these pages. Although this was preaching to the converted a little - I've been trying to practice the whole team approach for some time now - my attitude towards how developers support test and testers support development has changed a little since reading this. Breaking tests down into the "four quadrants", divided across product-critique vs. development-support and technology-facing vs. business-facing axes is basically a great, simple, tool for approaching testing in a more systematic manner, and this alone should help developers, testers project managers be much more productive.

There have been a few other books read, some to properly fill in the back story on Agile and Lean, but they aren't really worth mention, because they haven't changed the way I think, just deepened my understanding of how we have got to where we are.

So now my mind turns to what to read next. Well, my bookshelf - as always - contains a few recent acquisitions that I've yet to read; Pragmatic Thinking and Learning; The Goal; Crossing the Chasm; so it's perhaps a bit premature, but I'd love to read:

• David Anderson's Kanban, because I think that the Kanban board embodies many of the core principles of Lean and how to use a value stream to optimise productivity.
• Implementing Lean Software Development by Tom and Mary Poppendieck, as it's probably a criminal offence to talk about Lean without having read this.
• Tom Gilb's Competitive Engineering, because I believe in a methodical, engineering approach to producing any sort of product (let alone software), and Tom seems to be among the few "real engineers" in the world of software.

Treating the Development Department as a Business Within a Business

I've come to realise lately that no-one is going to sort out our problems as a development team for us. Seems a bit obvious, but let me elaborate a little. What I mean is that no-one is going to reconcile the challenges we face to produce software on demand while planning and developing for the future. In fact, most people outside a development team usually seem to make it harder, rather than easier to balance the two pressures.

What's the answer? Treat your development team like a business.

Like all businesses, development teams have incomes and outgoings, profit and loss. We produce a product not only for our customers, but for our company (in fact, many dev teams produce only internal products) and our customers don't pay us directly, rather the company does. So, it stands to reason that the company for which we work is our customer and we must treat them as such. This is probably more just a shift in understanding and perception, rather than a radical change in the way we should actually do things, but I think it's essential if we wish to grow.

I thinks there are two main areas of importance here:

• Income and outgoings
• What the customer wants us to do versus what we want to do

First of all, income and outgoings are perhaps a bit tricky, as a development budget is usually put on the company balance sheet as one whacking great loss. To make this work, we have to do some basic accounting ourselves. Our income is what the company is willing to put on the balance sheet as that loss. Our outgoings are what we pay our team and spend on resources. Simple, and the two figures should be equal (or someone's going to jail). But how do we spend that money? No private business really lets its customers tell them now to spend the money they pay for products and services, and they never will. That is because businesses plan to develop and grow, and they have to spend their profit wisely to do so. Within a development team, we aren't as free as the business, because when push comes to shove, we have to do what the CEO or the MD wants. But we should strive to give them what they need, while conducting ourselves according to a set of goals (consistent with the company's mission statement) that are created internally. If we can do this, then we can modify our internal balance sheet to have two outgoings:

• Developing what the customer has asked for
• Investing in future developments

The first of these isn't open to much negotiation in terms of price, scope or timing, but the combination of the two is. We must strive to sell a service to our employers that involves the timely delivery of software to a budget that results in a tidy profit at the business level, together with a promise of growth in terms of quality and market share. We do this by making sure we invest internally in the later of the two categories above. As much as people malign the pressure put on us by management, if management ask why you need to re-write your application (again!), can you really look them in the eye and say:

I told you so! We gave you a cost-benefit breakdown on quick-fix versus long term investment last time and you wouldn't listen!

And even rarer, perhaps:

We gave you lots of options for delivering the software you need and developing the next generation alongside, but you still wouldn't listen!

Maybe my weakness is always considering how I might be blamed for shared failure, but I believe it is our responsibility to have a long term technical strategy, to plan accordingly and to manage the expectations a business has of a development team. If we don't go on record and state our legitimate fears and offer solutions to mitigate them, then we can blame no-one other than ourselves if these factors are not taken into account by those making decisions.

Moving on to the next topic, how do we balance what the customer (our parent business) wants against what we want to do?

Take a "typical" project: the next generation app or website for your company. You know what you should do, you should "do it right", right? Re-write it, because it's so flaky now after 2 years of hacking and bug fixing and the core was based on OLD technology anyway. And there are some great new tools you could use to generate the GUI, new tools to generate automated tests and possibly even a different language you should be using now. However, the hard facts are that a polish of the existing GUI, a decent bag of new features and a big bug fix effort is probably sufficient to create a product that can start making the company money in 6 months rather than 18.

How do you make the case for what you want to do? Simple, you know why you want to do it, and it's because it's better in the long run, so just communicate this. But communicate it in a language that can be understood by the people who will be making the decision. More to the point, present options that aren't completely at odds with the goals of the people making the decision.

How about 9 months to deliver? in that time, perhaps promise to deliver a demonstrator of some of the new technology ideas you have, such that they are beginning to grow. Get agreement to commit some of your team to keeping this going out to 18 months and you'll have even more to show for it. OK, by your original "best job" projection, you won't have a finished next generation product, because you committed people to the quick-fix the company asked for, and as sure as eggs is eggs, you'll have been forced to commit staff to other projects after that. But you'll have something pretty decent to show for it. At this stage, your sponsors can start to get excited about the next generation of software that you can deliver, and this time, when they ask, you'll be ready for it. I've heard Tom Gilb talk of "front-room/back-room" development in relation to delivering successful software products using Evo, and I think this is a sound idea in terms of the business of creating software. This "Russian Doll" development department gives you control (hopefully) and the capacity to keep creating for the future, but you'll probably have to fight hard to protect it.

I'm not suggesting that this is easy by any stretch of the imagination, but I am saying that it's possible. Negotiating with your product management, sales and marketing people will be difficult, but - as I've already said - if you don't state your case, then no-one else is to blame for not knowing what you know. And as they say in the North-East, "Shy bairns get no sweets".

To wrap up, no business grows without internal investment, and I believe that to be true of a software development team, not just the whole business. It is our responsibility to ensure that our company's technology base moves forwards and no-one else's, so we must take the reigns and lead from the inside within our own team. Remember that our development teams are mini businesses and we must generate income in order to spend on what we believe is the right thing to do. A final point I would like to get across is that the person that runs a software development team has to treat their efforts in a business-like manner. Leaving all decisions about planning for the future in the hands of senior management is not as likely to produce results as entrusting it to someone fluent in the business of creating software.

Where Did Our Knowledge Go?

I found myself pondering where a lot of the knowledge created in our processes and code goes recently. I overheard some people discussing re-factoring some code. Re-factoring it to the way it used to be, although they didn't know it: they hadn't done the original re-factor. Now I found it rather difficult to give a convincing argument other than "there were very good reasons why we moved away from that", but I couldn't remember all of them: they had come from a variety of people and it was a decision made by consensus.

So where did that knowledge go? More to the point, how can we keep hold if it when we've made the same decision again. (And also, wasting a load of time discussing it and perhaps some time coding it before someone has the eureka moment and re-spots why it was a bad idea in the first place).

As I learned from Don Norman in The Design of Everyday Things, that knowledge of how things work should be "placed in the world", as opposed to in the user's head, and I believe the same is true of our code. Not just how it works, but why it is the way it is also. This was actually a bit of a u-turn for me, as I used to dislike code comments that stated a reason for change, or worse (as I then saw it), an original line of code commented out with a commented reason for doing so. Let's look at the ways our codebase contains our knowledge and how it can perhaps encapsulate and remember the decision making process for us.

• First of all, we strive to write code that communicates design intent implicitly: this is just good practice. However, all this effectively communicates is the way the code is now, and has no history.
• Comments are a good place for a more complete presentation of a design, perhaps including the reasons why a different candidate design might not be so suitable. One of our engineers lately told me that he was focussing quite a lot of attention on commenting the implementation of classes as much as their interfaces, and I can see how this helps to retain a lot of our knowledge by explaining the design criteria for the implementation, rather than just the final decision. Comments are fairly cheap, and there are many other reasons for commenting well. All that's required here is an additional perspective on the comment, a new reason for writing it.
• Our source code control system can potentially tell us about the decision behind changes, provided we write good commit messages. Thinking back over some of the commits I have made that covered a re-factoring, I can honestly say that I didn't record enough of the knowledge generated during that change. Most importantly, there possibly wouldn't be enough there to dissuade another engineer from switching back. Source code control is cheap, practically free, and focussing just a little more effort on those commit messages could potentially give a lot of bang for buck in the context of this discussion.
• Finally, good design documentation made as part of our development process can be an excellent place to look if you are reviewing the decision over a particular aspect of a design. This is, however, perhaps the most expensive ways to keep a record of the technical and design specification decisions that we wish to live on.

What have I learned from this musing? For a start, I've learned that my memory is nowhere near good enough 2 or 3 years down the line and I need a concrete recording of the way we design our software. I've also learned that I can rely on some automated tools to keep a track of these things for me, but if I want to be sure, then any decision making logic needs to be recorded, ideally at the site where it will be needed. Since starting this blog, I've actually put some of this into practice and done the following:

1. Written a load of comments in a few new classes to explain the reasoning behind the storage choices. I could just assume everyone has read Effective STL (and that's thankfully a valid assumption with my colleagues!), but that doesn't communicate the fact that I traded insert speed for fast iteration, because the class is accessed thousands of times per seconds, and only updated once in a blue moon.
2. Written much more complete commit messages that explain the original problem, what caused it and, most importantly, how the changes made addressed it.

Perhaps there are more code-bound ways to achieve some of this. I'm thinking along the "modern C++" that the likes of Alexandrescu propose, where policies can be used that embody the decisions quite clearly and explicitly, and most importantly in code. After all, someone can edit or delete my comments and the code will still work just the same. If I come back to any of my carefully crafted files to discover a carefully explained decision and implementation has been replaced with something new and the comment:

// This seemed to work better

Then I'll be pleased that someone improved on the design, but pissed off that they didn't care to enlighten me!

But I'm sure I'll continue in the same vein as I've set out on, as I've found that I feel much better about the code I've recently committed. This is because I'm much more confident about how it will be read and received by other coders down the line, as they'll understand the design process, as well as the end result.

Personal Kaizen

I look at the diary and, oh my, seven months have passed since I last updated my personal Kaizen. This is not good. It means that I'm either busy, extremely tired, or losing interest. It had better not be the latter of the three.

So what have I tried to make my professional life better? The truth is that I haven't tried much in the way of specific practices, gadgets, software or technology, rather I've focussed on some much bigger ideas. But first, the geek stuff:

• I downloaded and tried synergy and am extremely impressed! It's allowing me to seamlessly operate my XP and Windows 7 PCs side by side, keeping a total of 8 cores pretty maxed out when things are going well. The main difference to me however is a significant reduction in shoulder and neck pain as I'm no longer twizzling between two keyboard and mouse configurations! The next thing I need is a good free intranet shared clipboard...
• ...however, I used a very basic Windows feature (XP, Vista and 7) to help me with sharing just today, by copying all of the stuff from My Documents on each of my computers to a network folder and then pointing the My Documents folders to it: simple stuff, but the end result is quite pleasing, as the network sharing is effectively hidden, making it feel quite seamless.
• A solid state hard drive was going spare after someone left our office and I was recommended to use it as my build drive, as I usually have the biggest solutions to re-build (328 projects I counted today: usually taking an hour and a half from clean!) This has worked quite well and seems to improve the more stuff I cram on there that our code includes and links to. It'll only take one full build (source, libraries and binaries), which is annoying, as I build at least four different products from time to time. It quite surprised me that the SSD out guns a RAID0 for read/write access by such a margin, but the bottleneck is still link time: can only break that one down with more, faster processors...

So, that's the very thin list of widgets and practices; on to the Big Ideas.

• The first has been Communication. Dumb or what?! I found an old book about interpersonal relationships and psychology in a charity shop recently and it made me realise how much relationships affect our professional lives. I hope my colleagues don't disagree with any of this, but I now make a concious effort to listen when people are talking to me, rather than thinking about my next answer. I'm also finding it easier to read situations, armed with a little bit of the psychology and non-verbal communication ideas I've read. A really big one, which didn't just come from the old book, but from The Art of Project Management (Theory in Practice (O'Reilly)) also, is the communication process. That is, remembering that communication isn't just sending an email, the information has to be transmitted, received, understood, and acted upon. The chapter in Scott Berkun's book about "how not to annoy people" was definitely my favourite and the one that influenced me the most.
• The second thing I've tried to focus on has been Honesty. Make that honesty and courage. What I mean by this is being open about my thoughts on all matters at work (but in a professional way), be it whether I think we're doing enough to improve our development process, right up to expressing a fear that we might be making a very bad strategic descision. I always try to pose these issues as questions to allow a discussion to ensue, but sometimes, we have to grow a pair and stand up and say "no I completely disagree". Don't we?

What's next? Well, I've been reading Agile Testing: A Practical Guide for Testers and Agile Teams, and fancy putting that and some testing principles I learned at an IMechE training course on R&D project management into practice. Also, I've started to learn C#, so want to try it out on a side project in my own time.

So, a very poor first half of the year for personal Kaizen. Where has the time gone? I've no doubt the second half of the year will whistle by in just as much of a blur, but I feel more energised now than in the winter and spring - the number of posts I'm making here is usually a good indicator - so I expect I'll be managing more of my personal mini Kaizen events.

Doing Support When You Should Be Coding? You Didn't Finish Properly

While I was on a training course recently, we were going through the lifecycle of a project and looking at the transition from implementation to support. I realised that I often see people (and find myself) dragged through this transition. Why is this?

The only answer I can come up with is that finishing the implementation stage properly (designing and writing our software well) is key to keeping developers developing and empowering customer service and support to do all of the support and servicing. To discuss what I mean by "finishing" effectively, it's probably easiest to reverse engineer it by looking at what it is us developers are asked to do by support and service people, and even the customer:

• How does something work under the hood? This is applicable if you make scientific, mathematical or engineering software, because someone's going to want to know exactly what the frequency response of that band pass filter is or whether you've included radiation terms in your transport equations. Make sure it's documented (and unit tested to prove it does what you say). Even a well written pithy tool-tip can cover this kind of thing for the simpler cases, but it's most often going to need some comprehensive documentation. Of course, if it already exists in the public domain, reference it.
• How do I achieve my goals? Basic "user guide" stuff this, but if you haven't effectively communicated implicitly in the design or via the help and documentation, then people will keep coming back to you for this. You need to put the knowledge in the world for people, and documentation is the weakest form of this: better, make the way to use your software obvious in its interaction design.
• Does it do X? If it isn't obvious what the user can achieve with your software, then you're looking at the same problems as in the previous category. If you've implemented features that aren't in the specification and documentation, then perhaps you've just been doing the things you like, rather than what the product manager asked for. If you've done something good and it hasn't made its way to the headline, then you've denied the project manager the timely opportunity to get something into the documentation/help and make a fuss about it as a headline feature.
• Why doesn't it Do Y? This is perhaps a bit more of a product management issue as a development issue, but a strong product vision that covers all the bases of a users needs in a cohesive manner, coupled with conscientious implementation will not suffer these problems. If you keep getting asked, then find a way to get it done: campaign to your product manager to get it in the next service release or the next major upgrade.
• What just went wrong? Where's my data gone? Now this is even worse: if your software's making mistakes that people have to come back to you to unpick, then it's unstable and not worthy of release status. Recall it and test it before releasing back into the wild with a clean bill of health.

Every time we don't finish off and hand-over effectively, we burden ourselves with a few more support duties. At first it's OK, in fact it's flattering when someone comes to ask you something that only you know sometimes, but after a while it gets tedious. Is a quarter of you day too much to be spent answering customer queries and supporting the customer service team? Half of your time? Ask your manager and they'll probably have something to say about it.

Usability Design of an Iron

I've just been doing some ironing and suddenly saw the root of an infuriatingly bad design.

Ever get the annoying spit back and bubble blowing when you're re-filling the iron? I certainly do, and I just noticed that the way to avoid it is to put the iron down flat (as if I'm actually ironing something). Great, it no longer spits boiling water at me. However, now I don't know when to stop, as the iron's facility for telling me when it's full only works when it's stood upright!. Plus, I have to put it heating element down, so it's heating something up, or burning the ironing board cover (or worse, my shirt!).

What's the problem? Feedback and joined-up design thinking. There is feedback designed into the design for re-filling the iron, but it hasn't been designed in conjunction with the filling mechanism. Worse still, the filling mechanism has been design assuming the iron is off. I don't know any family men or women that have a small enough ironing pile to get through it with a single, cold fill at the start.

Rant over, I'm going to try and finish the ironing now.

Healthcare Innovation

While researching and discussing a talk I gave earlier this year about healthcare innovation, I believe I touched upon an interesting point about how and when innovations become commercial successes. The important turning points seem to be:

Commercial products infeasible before research and validation

Commercial success not viable until after standardisation or agreement in the community the products serve

I should probably attempt to trace this life-cycle in other fields and other products, but there are some important mechanisms at play here that I think would be hard to violate (specifically in healthcare and any other life science/engineering discipline).

Elaborating a little, my opinion on the life-cycle (of the successful product) is as follows:

1. Innovative ideas and methods
2. Research & Validation
3. Bespoke implementations
4. Highly specialist products and methods
5. Agreement/Standardisation of how the new methods should be used
6. Commercial products
7. Backing from within the community
8. Success

It seems to me that the factors that make the healthcare industry peculiar (and other life science/engineering pursuits), are embedded in the seemingly conservative and lengthy process of product adoption, and many are pretty immovable:

• Un-validated research is practically untenable in the world of healthcare, life sciences and engineering
• Some early commercial attempts are often needed to improve quality and efficiency of methods to make them accessible to a wider audience (the move from bespoke to specialist implementations)
• Standards and commercial solutions could well be switched in order, but a commercial success isn't on the cards without agreement between many users on the way to do things (and hence an empirical agreement to all buy the same product to do it!)
• A new product may well not catch on without some serious evangelical backing from a respected figure within the user community

Most of what we have going on here happens way before the "Crossing the Chasm" idea taught to us by Geoffrey Moore, and it could be described as "the leap from highly bespoke to specialist". Beyond this, businesses may wish to try to move from specialist to prosumer, from prosumer to consumer, but these are strategic business decisions that may or may not be feasible.

Of course, the savvy business provides products to suit their users for every step of the way and sells them many different products and services to suit their changing needs as time goes by.

Sleeping under a Hanky: Managing with Few Resources

We've been looking over performance on a couple of projects recently and I find discussion of issues surrounding how we managed our scant resources and tiny mistakes that caused big problems frustrating. I feel that nit-picking about how this little problem, that tiny delay, this mistake or that bug caused major problems is ignoring the elephant in the room:

We're trying to keep warm, sleeping under a hanky: We need to stop seeking the optimal position for the hanky and go get a blanket!

Now this probably sounds like a cop-out, but it certainly isn't. The blanket is something I'm always shouting for, but ultimately can't conjure up for us without some serious support. My point is simple:

While we're sleeping under the hanky, the risk of freezing to death is high. No amount of effort can hold back the inevitable tide of probability and prevent sheer bad luck from forcing some projects into failure or at least some seriously embarrassing shortcomings. Success tends to be down as much to good luck as good management (and I believe this of many of my own projects).

Tips from the Greatest Leader I Know...

So, my Dad's led quite a few people to various ends: in business, in local government, in military action, in sport and as a Dad. A slightly tipsy conversation with him this evening on the topic of leadership provided a rich seam of simple rules and maxims that will stick in my mind.

You have to inspire people

The secret is delegation

Good leaders sit back and let others come up with the ideas

What are you doing to prioritise your day?

People won't follow you if you're not confident about where you're going

The first thing to do is talk to everyone

If you don't give people the chance to fail, you deny them the opportunity to grow

Now, you'll no doubt reckon that I'll have an extremely biassed view of my Dad's leadership qualities. After all, my desire to please him is built in from year zero, so I can't comment on how or why he's succeeded in raising the bar for me and helping me to meet it. I think I can say for sure though, that there's a lot of years experience and wisdom crammed into those few pithy comments.

Why 5S Applies to Software Engineering

I've heard a few comments lately about how the Toyota Way practice of 5S is not really applicable to software development. The argument usually goes along the lines of:

We don't need to tidy up: everything we do is inside a computer.

This worried me for some time, but I only recently realised exactly what the problem is with this: 5S is not about tidying up, it is about minimising waste.

In relation to the manufacture of auto-mobiles, Taichi Ohno identified seven wastes:

• Overproduction
• Unnecessary transport
• Inventory
• Excessive motion
• Defects
• Over-processing
• Waiting

There have been additionally proposed fundamental wastes in businesses, most notably:

• Goods that don't meet user demand
• Unused human potential

In software development, only some of the physical wastes at first seem to apply, but I suggest that almost ALL of the wastes apply to software development. Just think about it.

Are You Committing "Pragmacide"?

After the umpteenth time of hearing someone saying:

We've got to be pragmatic about this

(when they really meant lazy), and:

Sometimes, you've just got to take the hit

(when they meant we ALWAYS take the hit), I came up with a new phrase: "committing pragmacide".

I reckon it's fairly obvious how slow and painful committing pragmacide is: death by a thousand paper cuts as I've heard it described before. Maybe you can use the term "pragmentation" of your code-base when quick-and-dirty, re-branded as pragmatism has moved in with your team's practices.

As far as I can remember, pragmatism is about "doing the right thing, all things considered", not doing the cheap thing with very little considered. Or maybe I'm just getting slightly older and grumpier.

2010 Medical Engineering Student Project Competition

We're holding our 22nd Annual Medical Engineering Student Competition at the Engineering in Medicine and Health Division of the IMechE on the 23rd of June this year. The deadline for applications is 12th May, with prizes of £500 for undergraduate projects and £750 for best thesis.

It's always a pleasure to chair this event and the students never fail to amaze me with how much better they are than I was at their age!

Creating a Better User Experience: Write a Quick Start Guide

I had to check and polish up a "Quick Start Guide" for some beta software recently and it was a much more powerful exercise than I was anticipating. This is something I'll now try do for every project I'm on, as it help flush out usability issues from the tiniest details such as common terminology to the very large issues such non-intuitive work-flow early on in the process.

To create the Quick Start Guide, we start with the product vision and sketch out the grand user story. From this, we can then then graft on the specific references to the software, how it supports the users needs and how they have to operate it to achieve their goals. Issues then begin to surface in five major areas (although I'm sure usability experts and designers would find more than I have).

1. Work-Flow Vision. Does the software live up to the vision for the solving the users' problems? If we find ourselves jumping around a lot in the software to achieve things, then odds are that it isn't properly aligned with the vision. This is a very compelling reason for doing something like this as early as is possible. Leave it until the end of a project, and we're forced to twist the vision to fit what we've done, live with the embarrassment and hope our users won't hate us for it. Of course, getting the software and Quick Start Guide into users' hands early is as, if not more important than the guide itself, as they're the real arbiters of usability.
2. Intuitiveness. Does the context of UI elements need to be explained so that they are meaningful? If so, then the interface isn't communicating its purpose efficiently! For example, "...click Start to begin translating the document": the button should probably read "Start Translating" or "Translate Document". Controls that have different effects in different contexts should also be a cause for concern, as this requires the user to build up a complete picture of the internal application state in their minds. Remember, we already have that privilege because we wrote it: the user does not, and will rapidly give up if expected to hold too much information in their heads. Finally, interactions we force the user to make that don't seem to be relevant to their task should also be stamped out. For instance "click Initialise Dictionary to load the language definitions into memory, then click Translate to translate the document". Make it obvious, make it unambiguous and make it matter.
3. Feedback. It's good to end important work-flow steps by letting the user know what visual cues they expect to see. For example "The file will appear in the Translated Documents area" or "a green tick will appear to indicate the operation completed successfully. If a red cross appears, it means there was an error". If this can't be written down succinctly, or there is nothing in the UI to communicate this, then we need to go back to the drawing board and figure out how to add this to the software. A bad example would be "the translated document can now be found using Windows Explorer in the Translated Documents directory set in the User Preferences". When feedback is required to communicate problems, it should focus on the exact error rather than general failure. There's nothing worse than "there is an error in the form". What error? Where?!
4. Illegal Operations. Illegal operations are those things we may need to inform the user they shouldn't do because of the negative effect they may have. Whether the reason is an adverse effect on performance or - the worst kind - something that will cause a crash, it should be fairly obvious that this is cause for alarm. If there is any interaction that can break the software, then it should be locked out. Operations that may have a more subtle negative effect should be warned against in the software, not in documentation, for example pop-ups that say "...this may take some time..." or "...this will break backwards compatibility with version 1.1". For long running operations, a modal progress dialog is a simple solution. Selective greying out is also common for locking out UI controls that could endanger processing, although whole application mode switching can be a much stronger visual cue.
5. Terminology. Is the same terminology used everywhere in the Quick Start Guide and the software? A good way to start kick-start this is to introduce specific terminology and concepts in a short introduction to the Guide, and this may even reveal ambiguities or gaps in the overall vision. Consistent, meaningful and succinct UI terminology (and even spelling and grammar) is all too easy to leave out (how important is it compared to some low level bugs?), but it is incredibly cheap to fix and has a big impact on the user experience. While content and functionality is undoubtedly important, the user experience can make or break an otherwise great product. This "polish job" can be made easier by staying on top of it all of the way through development, and the presence of early documentation as a visionary reference for terminology and work-flow concepts can really help everyone stay on the same page.

Finally, another excellent tip from my Product Manager (thanks Derek!) was to get someone to read the Guide that has never seen the software before! It's easy to overlook the fact that the project team all carry implicit knowledge about the software (together with their pre-conceptions and prejudices).

In suggesting early documentation as a big help in maintaining a strong vision for the user experience, I'm by no means implying that it can replace a strong product vision: this is absolutely vital in creating what's best for the user and successfully guiding a project to success. However, having seen the powerful revealing and magnifying powers of the Quick Start Guide, I'd recommend it as useful tool to help communicate and implement product vision.

Happy Workers are Better Workers

Lately, I've been thinking about the ways our jobs satisfy us, or on the flip-side, can get us down. Don't get me wrong, I'm happy with my work, but I've been reflecting on the times this hasn't been the case and - for me at least - can see four contributing factors to job satisfaction. Note that I'm talking about job satisfaction, not our employment situation, which is naturally influenced by much baser instincts: pay, prestige, even physical comfort and the quality of the food in the canteen.

Let's go through the elements of this diagram.

Commitment

This might seem like a low level, even fundamental aspect of someone's relationship with their work and my experience is that it comes a little later in life. Like taking full responsibility for our actions, this is at its best when we've matured. Professional commitment is what gets us into the office on time despite feeling ill and what keeps us checking our email in the evenings and at weekends. Without commitment to our jobs, we simply won't make the time and, worse, may start slacking off. Commitment is largely reciprocal: we commit to our employer when they commit to us, and decent management keeps this part of a work relationship alive.

Belief

This may also seem odd, but believing in what we do makes us more productive as we do it. Few of us likes being told what to do if we believe it's the wrong thing to do, but if we believe in our goals, then we'll try extra hard to achieve them. Although some beliefs are held very personally and are hence difficult to change, believing in what we do can be influenced by good leadership.

Care

Caring about something is intensely personal and difficult to influence: it's much more difficult to change what someone cares about than what they believe to be right. In the employer-employee relationship, this is one aspect we aim to get right at the very start: we gravitate to vocations and employers about who's business we care. Similarly, when recruiting, we seek individuals who resonate with our overall plans.

Personality

I've put this at the centre of the diagram, as I feel that this is the core, around which all of the other work satisfaction factors are built. Personality dictates how much of each of the other factors an individual requires to top them up to "satisfied". There are individuals who will give their all to any task, no matter their feelings on it, but they are a rare find indeed. More commonly, we all demand a certain amount of each in order to enjoy our work. Failure to meet some or all of the satisfaction demands will result in degradation of the relationship and the quantity and quality of our output will fall.

Looking at these values, I feel that the relationships between them are also interesting and worthy of note. It's possible, I believe, to enjoy any of them in isolation, for instance to be committed to a job we believe to be a waste of time: this is raw professionalism. Likewise, it would be possible to care deeply about the work you do, but believe that you're still being asked to go about it the wrong way. However, add these things together and we get more and more out of our jobs (and our employees!)

Being committed to something you believe in is to be dutiful. This gives people a greater drive toward excellence in what they do: a valuable thing.

Committing to something we care about is dedication, which keeps us in it for the long haul. Once dedicated to something, we start making longer term plans about our jobs and our future potential grows.

Passion results from believing and caring (and I don't mean the kind of "passion" cited by those prone to losing their temper over things they care about: that's old fashioned short temper!). From this position, an individual can influence those around them: evangelise their work, teach and begin to lead others toward their goals.

At the centre of the Venn diagram is devotion. Once we're here, wonderful things can happen. Within devotion lies real leadership: dutifully holding true to what's best, the commitment to lead from the front and do yourself what you expect others to do for you, and the passion to inspire and teach. If you look around your company, you may well find people in senior positions who aren't completely devoted, but I'll bet that the MD is. To make it all the way to the top, we must show clear duty, dedication and passion for our work.

Of course, you may ask why should we pay heed to this emotional nonsense and liberal talk of personality traits, because after all, we're professionals and we have to do what's expected of us to the best of our abilities despite our personal feelings. That's the nature of work, right?

The difference is what the "best of our abilities" amounts to.

Not committing to people will undermine their ability to commit back and you'll get fundamentally less out of them, no matter how you deal with it. Decent, good quality management is important, but so is company ethos: an exploitative culture with no respect will prevent even the best manager making good on this part of the job satisfaction contract.

As mentioned earlier, belief can be influenced by good leadership. Persuasion is much better than dictation, but requires skill: only the strongest leaders can hope to get anywhere near to 100% from people if they ask them to blindly follow.

Finally, we can't change a persons ethics, so we must tailor tasks to what each individual cares about. This is no simple task, and there are always jobs no-one wants to do in a company. Savvy leaders know their staff and, where possible, play to strengths, and can otherwise gently persuade people that they care more for something than they originally thought. I'd rather not use the word manipulation, but you get the picture, and it's going on all the time without us noticing.

A final word before I sign off probably my longest blog to date and that's to remember this simple, old maxim about most people:

We work to live, not live to work

No matter how dedicated we are to our jobs, our family and friends will always be top of the list. They can be displaced for a short time, but if this persists, then we are asked to give up that which makes us truly happy, and we won't be thankful.

What's the Difference Between Lean and Kanban?

Maybe I just need to read more about the original concepts for Lean software development, but the more I see written about Kanban, the more I think it's just re-branded Lean. Before you jump off the deep end with me, my idea of Lean is more like that which you'll find in the Toyota Way or Deming.

Looking through the entries in a recent definition of Kanban blog post, all of the things mentioned are core Toyota Way values:

• Systems Thinking
• Limit Work in Progress
• Pull System
• Mapped Value Stream
• Cadence and Flow
• Visual Signals

Now, I'd happily use any of these points in a description of what I consider to be Lean, but I'd always want to include the pre-requisite of:

Continuous reflection and improvement based on a culture of learning and standardised working practices.

Maybe this can be wrapped up in the phrase "Systems Thinking" and I should remember the 130 character limit on people's descriptions when considering what they left out: They will naturally be a top two or top three and a poor reflection of each person's complete set of beliefs about Kanban I'd clearly fail to get my ideas into a single short sentence, it's taking me a full blog post!

Perhaps as a community we need clearly defined methodology brands, which is why we've always had these strong, product-like names (such as DSDM, XP, RAD, Evo, Agile and now Kanban). (Branding is a definite positive if you're trying to sell books or a consulting service). I've no objection, but I prefer to avoid describing my beliefs using these terms, as it suggests that I'm all for one set of ideas and dead against the rest. If pushed, I'd maybe say that I'm a "Lean Pragmatist", but would more likely describe myself plainly as an Engineer with a desire to get it right.