Anti-Pattern #5: Always Finish The Job

We're taught, when we're young, to finish what we started. When adults preached this, it was presumably because everything that we were supposed to do started and ended with a simple set of values that never changed. When your room's untidy, Mum isn't going to change her mind half way through the day, and say that tidiness is no longer her #1 objective. And when you've started sweeping the yard, Dad was never going to change his mind and decide that, hey, leaves are cool, and why don't we just leave them there?

But things aren't quite so simple in our professional lives: things change, and things can change pretty damn fast.

Anti-Pattern #4: Give Work To The Lowest Bidder

The idea of giving work to the lowest bidder is very commonplace throughout many industries, and our personal lives also. After all, we're interested in saving money for ourselves and our clients. But, there's the old adage that "you get what you pay for", and there in lies the rub: if something's too good to be true, it probably is. "This is just anecdotal waffling" I hear you all saying, so I'll break it down.

To start with, it's worth me being specific about the type of work and the type of bid I'm talking about: it's for agreed scope and quality software work, but not fixed price; with a contractor, or even an internal division, team, or individual.

Anti-Pattern #3: Cheat To Win

If ever there was a phrase that I've heard in project management that made me immediately worry, it was "Cheat To Win". You maybe need some more context to understand, and perhaps some alternative phrasings that may ring a bell. Try "Quick and Dirty" or perhaps even "Low Hanging Fruit". Ringing any bells? Good. No, that's bad!

To examine why I think that this type of practice is almost always a terrible mistake, I'll look at the two important words in the title and ask:

Who (or what) are we cheating?

What is it we're trying to win?

Anti-Pattern #2: Make Customers Wait

The full title of this anti-pattern is "Make customers wait until they can all be satisfied simultaneously", and it doesn't really need much more explanation than that at first glance. This is rather related to "All projects equally late" in some ways, as it's a lack of focus and a failure to prioritise that underlies the problem.

But put simply, this anti-behaviour is turning down an opportunity to deliver finished software now, because there are fixes or features required to satisfy some users left to do. I stress some users, as I don't necessarily mean the minority: I believe that it should be possible to release software, or software upgrades, explicitly for one group of users only, with the clear intention of releasing something else for other groups on another date.

You might ask yourself - as I have - why very bright people; with the best interests of the users at heart; will actively force a large number, even a majority of users to wait for features or fixes that are ready genuinely ready to go and can be delivered right now.

Anti-Pattern #1: All Projects Equally Late

To kick of this little series of software project management anti-patterns, I'll talk about the one I first noticed: "All Projects Equally Late"

It must have been a couple of years ago that I observed a pattern occurring across multiple projects during attempts to "load balance". Sadly, I have seen on many occasion, the project that is on fire (most late) have resources pulled onto it from projects that are within bounds, then - surprise-surprise - these previously comfortable projects run into problems a few months later. The projects that we're on track, having been pillaged of their originally allocated resources, fall behind, and they eventually become equally critical and late, and the cycle continues.

Software Project Management Anti-Patterns

Anti patterns are often a great way to sum up the thinking behind a set of patterns by stating a small, highly exemplifying set that sums up exactly what we shouldn't do. In some cases, they are the best or only way, because the patterns we want to communicate aren't quite so easy to elucidate, are too many, or too varied.

I find some aspects of project management to be like this - not because of the way I understand it, probably more the subtlety in communicating it. In particular, the more tacit knowledge gained when learning to project manage is very difficult to communicate. But I'd better give it a try, considering I believe communication to be a significant cornerstone in an ability to project manage...

How Bad Code Commit Habits Hide Problems

Commit habits, it seems, are highly personal. I know people who commit incredibly fine grained work, and I know people who commit X thousand changed lines regularly. Who am I kidding, I just did that yesterday. And last Friday... There's good and bad in everyone's behaviour, and I'm interested to think about what's what in this particular case. Most importantly, it seems to me (and others), that bad code commit habits can cause terrible de-coupling of the inputs and outputs of the development process from the coding itself.

I was initially inspired to write a few words on these matter by this post, and I've been reminded to finish it by the new tester on my team, Sona, who's come from a class IV medical devices background, where their auditor insisted that every single commit was linked to a defect or change request ID.

Part of me wants to pursue this at Vicon, and part of me knows that I'll get a hard time doing so, so where's the middle ground?