Monthly Archives: October 2014

Roadmap

The Importance Of… Roadmaps

Development, , , ,

I started the off the Importance Of… series to write about some aspects of software development which are sometimes overlooked. In what was going to be my last post, I mentioned in passing roadmaps. In particular, I said that customer-led developments shouldn’t affect or obstruct the roadmap. The rationale behind this is simple – the roadmap defines where you need to take your product; it effectively defines the primary development objectives. Anything detracting from your primary objectives will by definition be an obstacle for your product.

In the first place then, a roadmap will force you to think about the priorities, risks, and rewards of developments planned for your product. In turn, this clarifies the direction of the product – where it’s heading and what it’s aiming to do. And direction is invaluable when it comes to engaging with people, both internally and externally.

Externally, providing a roadmap to customers will boost confidence. It demonstrates that there are objectives, a thought process, a plan. Existing customers know what to expect, can start planning for those deliverables, can see progress as roadmap items are delivered. Potential customers can determine whether it’s the product they’re looking for now or in the future, can see it’s an active project with progressive thinking. A roadmap shows your customers that you are committed to improving your offerings.

Internally, that direction is perhaps even more important. It ensures that everyone is working towards the same goals. Aligned objectives means less friction, and more clarity on what to work on now and next. From a software development perspective, it means it is easier to keep multiple development teams in sync, and easier to plan and schedule work. Dependencies across teams can be identified and taken account of.

For developers in particular, having a roadmap can make architectural decisions a less daunting proposition. People sometimes refer to future-proofing a feature or development. While it is technically impossible to future-proof a software product (the 640K quote, while a misattribution, remains a great cautionary tale), knowing where a product is headed can certainly reduce the number of problems you encounter in the future. It allows developers to consider flexible approaches, discard ones which will not work when other developments come into play, or even delay certain aspects until they can be kept in step. [As an aside, the term future-proof isn’t great for software development, can we use future-harden instead?]

A roadmap is an essential part of any company strategy. Without one, you are lost.

Photo by Scorpions and Centaurs via flickr.

Pumpkin Carving

Notes, , , , , , , ,

Every year I spend some time carving a pumpkin, usually with some relation to a film or TV show from the past 12 months. So last year, I carved out Walter White/Heisenberg, as a homage to the end of Breaking Bad (and also, because, you know, “I am the one who knocks” totally makes sense for Halloween).

Walter White Halloween Pumpkin 2013
“I am the one who knocks” – Walter White/Heisenberg

The year before, I honoured the end of the Nolan Batman trilogy, carving Bane from The Dark Knight Rises.

Bane Halloween Pumpkin
Bane from Christopher Nolan’s The Dark Knight Rises

The year before that, I went with a zombie from The Walking Dead. The TV show had started the previous Halloween, so I hadn’t had a chance to use it then, and I love the comic, so it seemed fitting (not so impressed with the show since).

Walking Dead Zombie Halloween Pumpkin
Zombie from The Walking Dead

This year though, I’m at a loss. There hasn’t really been anything that has come up that seems to fit all that well for me. I recently watched You’re Next and loved it, but it’s not exactly recent. So if you have any ideas, let me know in the comments.

EDIT: After considering The Strain, I did end up going with You’re Next:

You're Next Fox Mask Halloween Pumpkin
Fox Mask from You’re Next
Listen

The Importance Of… Listening To Developers

Development, , , , , ,

Everyone’s heard that you should listen to your users, right? After all, if you don’t, you risk alienating and losing them. My particular favourite take on this is Jeff Atwood’s, of Coding Horror, Stack Overflow, and now Discourse fame (and if you don’t know who Jeff Atwood is, where have you been?). He wrote a blog post called Listen to Your Community, But Don’t Let Them Tell You What to Do. You can see this way of thinking in a lot of successful websites and applications – if Facebook didn’t follow this path, it would have died years ago after reverting every change users complained about. In a way, this also applies to software products where customers pay for developments – by all means allow this, but don’t let that affect your roadmap or you will end up without a product.

Somewhat less popular, but still going strong (and perhaps growing stronger with the appearance of shows like Undercover Boss), is the idea that you should listen to your employees. An interesting take on this can be found in an article by Matt Linderman (of 37Signals/Basecamp) called Marketing to your own team:

You’re not just sending out a message externally, you’re sending one out internally too. If your employees don’t believe it, the whole plan falls apart.

It’s not good enough to just have meetings where employees talk to you – it’s all just platitudes if you’re not engaging in a conversation. Listen to your employees, market to your employees, or they will lose interest.

Of course, this is just one of the reasons you should listen to your developers. From a technical perspective, and in the absence of empirical data (such as usability studies), developers should be your first port of call when it comes to figuring out how to develop your product – they know your product inside out, to at least some degree they are invested in it, and they have an interest in what you’re doing (at least, I find web application developers have a general interest in the web). If they didn’t they wouldn’t be there. Their knowledge and their input is valuable, whether it’s suggesting improvements to customer requests, or strategic direction, because they understand the expectations of software products.

Ignoring developers’ input risks alienating them. It can demonstrate a lack of trust, and a removal of responsibility. And employees who feel alienated, or without responsibility, will soon leave. High staff turnover will in turn lead to other problems. Knowledge loss, leading to difficulties in maintaining and developing the products, is perhaps the most obvious. In the highly interconnected development community, it can also make recruitment difficult, which will make any recovery harder to achieve. And if the turnover cycle is short enough, you will end up unable to promote internally. For example, junior roles tend to last 2 or 3 years, and mid-level roles anything from 3 to 5 years. This means senior roles are generally available only after 5 to 8 years. If you’re losing developers after just 2 or 3 years, the knowledge loss will be severe, you’ll be spending a lot of time on training which you don’t get to see a return on, and you’d better hope the code is very well documented.

Photo by Ky via flickr.