Wednesday, 30 December 2009

Software Development Best Practices: Enabling or Stifling?

It seems that the arguments for and against best practices and standardised ways of writing code will never cease. But what motivates people to be strongly against or vehemently in favour of best practices?
  • Fear and distrust are big issues, and it's no surprise that people fear losing control over what they see as a creative process to best practices, boiler plate code or standardised working practices. The way in which arguments for best practices are presented may affect whether they are perceived as a threat or not.
  • Understanding is another key area here: differences in people's perceptions of what constitutes "best practice" or "coding standard" will undoubtedly lead to differences in levels of acceptance. Inconsistency between perceived requirements and constraints imposed by best practices and the other pressures present in writing good, solid software are a close cousin to understanding (or misunderstanding) standards and best practices.
  • Finally, personality is an unfortunately big part of this: developers are extremely independent thinkers (which is no bad thing) with strong independent personalities to match. Ideas such as coding standards and best practices can seem too authoritarian for many, so may be resisted simply because they "feel wrong". Worse, an idea can fail to be adopted by an individual simply because it's put forward by someone they generally disagree with or even personally dislike.
Best practices come in many shapes an sizes (of course depending on opinion), but lets lay out a few along the continuum:
  • Low level best practices such as memory management or object storage. For instance "always use boost::shared_ptr rather than a raw pointer" or "avoid using a vector of std::auto_ptr". Such ideas are really rather hard to argue against: the ideas are about avoiding common pitfalls and bugs. Of course there are (rare) situations where we may need to diverge from such rules, but a coding guideline should at the very least make it necessary to justify your decision to do so.
  • Next come mid level ideas such as common pattern usage. For instance a standardised way (or a couple of ways) to do Observer may be recommended. How much you can standardise through generic code, boiler-plate or simply guidelines is language dependent, but it's at this level that divergences in opinion start to form. Observer is a great example, as you don't have to write too much code to find that a generic "Observer with Hint" template might not appear to be enough: you might need two hints, visibility both ways or perhaps two types of observer. The balance that needs to be made at this level is the cost of modification to the code that uses the pattern versus the cost of partial duplication of a new pattern variant. These costs can be in time to code, clarity, maintainability and bug fixing.
  • Finally, the largest ideas we might consider putting forward as best practices are architectural paradigms such as "all communication via asynchronous events" or "no database access on the non-GUI thread". Such rules are unlikely to be effective across many projects, but are suggested to be essential ideas in XP in the "System Metaphor".
Lean manufacturing suggests that standard working practices are at the heart of continuous improvement, but those using them must be empowered and motivated to improve them. If developers are in charge of their best practices, then it's less likely that they will be viewed as an authoritarian diktat. In addition, issues of trust and respect becomes potentially less thorny, as the standards are maintained by a group of peers by consensus. Going back to an earlier example, if someone has a real need to diverge from a best practice such as a generic Observer pattern, then the particular problem they are trying to solve should be discussed and the standards amended if needs be. The main point of such an exercise is to inspect and adapt standards and best practices to suit, rather than view them as something fixed.

Tuesday, 29 December 2009

Kanban Style Project Development Status

I was talking with a colleague this morning about the beautifully simple and effective way the Toyota Production System embodies Lean tools such as Kanban, Andon and so on using stationary supplier and thrift store bought bits and pieces such as laminated cards, coloured flags and so on and an incredibly simple idea emerged for managing multiple projects.

Say you have three big projects on - we'll call them "The Big One", "Middleweight" and "Express" to illustrate the fact that they're of differing importance. Management have made decisions about available resources (or people as I often like to call them). It has been decided to dedicate 3 full time developers, 2 testers and one product owner to The Big One, 2 developers, 1 tester to Middleweight and 1 developer and a part time tester to Express. Middleweight and Express will share a product owner.

Why not just create a few simple coloured cards for these? 6 big red ones for The Big One, 3 big green ones and one small green ones for Middlewight and 1 big yellow one and 2 small yellow ones for Express. Write the project name in big letters and "Developer", "Tester" or "Product Manager" on them accordingly and place them in a marked out area on a table. When you allocate your staff, they take a card and pin it over their desk somewhere visible. No-one is allowed more than one big card or two small ones.

Now, take a look at the "holding pen" we created on the table: are there any cards in there still? If so, you know you're under-staffed and in what area. Look around the office: has anyone got more work on than they should, or is anyone seriously slacking? Smashing, everyone's got just the right amount of work on :)

Now, obviously, we have to manage other activities: the odd emergency here and there, process improvement, perhaps some personal learning and so on, and we should create temporary cards for these. So, for example, you have a Big Emergency to deal with on a legacy project or for a demo and you need to pull someone: grab a temporary wipe-clean card and write it on. Go pick your developer/tester/PM and they pin this card up. Obviously, any work they have on that takes them over their limit has to come down and go back to the holding pen.

Now you can see the effect that the emergency has had. When the PM head walks past the desk and sees a big red card in there, they immediately know that something's awry and can start asking questions. No cards in there and they're happy.

Monday, 21 December 2009

Personal Kaizen

I've missed the first Monday of the month by a mile, so I'll roll November's and December's Kaizen into one. Where did this month go?!

I've been continuing to try to increase the integration of planning tools on a Sharepoint site for project management and probably reached a sensible end point at the beginning of December. Any more work will be too much for a diminishing return. However, this seems to be the month that a turning point has been reached: we have Product Managers suddenly interested in Agile techniques and a department head showing a keen interest in moving our ad-hoc methods towards a more unified tool set. This represents both great opportunity and a challenge. It's a time for enthusiasm and commitment for the future, yet also caution and careful decision making.

I've rather failed to get regular GCC Linux builds going, which is annoying and this still needs to be done, as I think this has the potential to push up the quality of my code. This effort was unfortunately hijacked because my main Windows box died and the box I was ready to install Linux on was suddenly needed to do all of my work. Now, I have three windows PCs, which should reduce to two (when the worst of the bunch is rejected). One will then be turned into a Linux box, or perhaps have a Linux VM installed.

I also promised myself that I'd look into how the Toyota principle of Jidoka could be applied in our process. It seems that many people share a view on this, but know it by different names and arrive at it from different perspectives. There seem to be two things that we can do in the relatively short term
  1. It's emerging that if we can all "move to the blockage" in our development line when a Big Bug is discovered and focus on getting it moving again, then productivity will actually go up and worries that highly paid developers will be doing menial testing are unfounded.
  2. We have to solve the "root problem" before we re-start the line (part of the principle!), and there seems to be concensus that this normally means putting the automated tests in place to prevent similar show-stopping bugs ever making it to QA again.
I've had some interesting side benefits this month after installing Windows 7 on my main PC after it was repaired. There are just a handful of productivity shortcuts that really seem to keep things moving fast without me having to actually use the operating system much at all! Also, a simple system for mirroring our centralised automated build and test system on local machines has proved incredibly useful in flushing out bugs in merges of release branches to our trunk prior to committing the changes, and it all happens while I'm safely tucked up in bed.

Next month I've a few things down, which I'll report back on at the beginning of February:
  • My GCC Linux box or VM.
  • Looking into ways to inject a bit of FMEA into our processes without too much effort.
  • Find some good project management courses before my CPD assessment: Masters courses hopefully.
  • More books: I seem to be coming to the end of the last pile a picked out.
  • Find out if I've become a Chartered Engineer!

Friday, 11 December 2009

Project Management Top Trumps

Ever get the feeling that discussions about project management are turning into a game of Top Trumps? You suggest an improvement to the way you might do something and you get the response:
That's the least of our worries
I disagree, THIS is more important
I'm sure this happens all the time, and it's a close cousin to "Escalation" that seems to be talked about in the Agile/Lean blogosphere at the moment. Although it can seem to be quite counter-productive, I've been wondering how to interpret and use such opinions and feelings, because when someone says this to us, they're not lying: it's truly the way they feel and what they believe!

Having thought about it a bit (and I stress "a bit"), here's my thoughts on what we should do when the Top Trumps start:

First of all, think about whether it's a fair point and if it does truly "trump" your original idea. That is, you can't begin on your idea until the suggestion is dealt with. For example, you've suggested doing more TDD, but it's pointed out that you don't have a working test framework: they're right. You'll need that testing framework sorted first if you're to make a go of TDD.

If you aren't "trumped", then there's still the issue of which idea is most important. Unless the counter idea can be just as easily implemented by you (if you intend to do it yourself) or would have a much greater impact to balance the increased cost of doing something you're not familiar with or don't have the resource, responsibility or authority to carry out, then your time is probably best spent on your original idea. Be sure to explain this rough cost-benefit analysis to the person you disagree with, particularly if they're in charge!

If there aren't clear priorities, then think about whether the various topics that have been thrown into the discussion share anything. If you can find common ground, then you have an opportunity to get more done, because of a shared goal. If you can't find common ground, then you'll have to agree to disagree. If someone believes with equal passion in something else, then why not just do both? You do your thing and suggest that they do theirs (rather than expecting you to do it for them). This brings me on to the last point, which is very important if many people have different agendas and that is...

Make sure you're pushing in the right direction! What you suggest must be in line with overall strategy if it's to have a positive impact. Absolutely make sure you're not going against the grain: if you really want to and believe that's the way forward, then you have to obtain some serious buy-in at a higher level, because you wont be thanked for sabotaging existing efforts with your own agenda. Lots of different opinions could be symptomatic of an overall lack of clear strategy - a serious problem - but we're generally a highly opinionated bunch, so we have to learn live with disagreement and confrontation, particularly when the stakes are high.

Sunday, 6 December 2009

Learning from Our Mistakes: Using FMEA in Software Development

I've heard the phrases so many times now:
We've learned from our mistakes
We won't make the same mistakes again
However, I've not been privy to an explanation of how this will be ensured. If I make a mistake, how do I make sure that someone else doesn't repeat it? If someone in our US office found serious problems with a tool they use, how do I know and not get burned the same way?

The answer in engineering is Failure Mode and Effects Analysis and this has been applied to software development for many years now.

Everyone tends to do their own slightly home-brewed version of FMEA that fits well with their processes and systems and I'm keen to try the techniques out. As a first step, pooling all existing knowledge about foreseen and unforeseen project problems, delays, failures additional costs and so on should be pooled. This pool of knowledge should then be used as a starting point for any future risk analyses, rather than it being an exercise in memory, intuition and guesswork.

I've been reading around a little and found the following useful:

I think I'll set myself the goal of kicking off a closer look at FMEA as my first personal Kaizen of the New Year and will post back here as usual.