Moving to Deployment

A critical aspect of any technology project is how to move from the stages where you do all the heavy lifting and hard work, over to the stage where users can actually use the system.

Flat Design Icons Set Of Vector Line Prototype Promote Idea

Some would say that the heavy lifting starts there!

Getting the system to the users can be hard – despite the fact that the obstacles are well-known, have been with us for as long as I can remember, and are really not so hard to avoid – challenges remain, and they are significant.

For example, often some of the most critical people in the project don’t become involved until the eleventh hour. If it’s an enterprise line-of-business application, maybe you didn’t talk to the folks on the fifteenth floor in Marketing about what they really need the app to do.

If it’s a consumer-facing product, maybe you didn’t get any real users onto the system during any phase of the development and testing.

Another way things can go – sort of the opposite of not getting the right people involved until too late – is kicking people off the project because you don’t see their role as being one closely involved with deployment.

For example, a new system will have the potential for a huge number of bugs in core functionality as soon as it actually gets in front of users. In fact, the software might seem practically unuseable at the start. But the best people to fix those bugs are already working on something else and consumed with new problems.

So get your developers into the deployment!

Assign one of your most trusted programmers to be immediately available to fix problems: Fix the problem, get the users back running the system, get more feedback, improve the system, etc…

Both of these are good ideas – basically getting and keeping the right people engaged at the most critical moments.

And yet, we rarely do either of these things, and we feel the impact of the poor alternatives.

Deployment doesn’t have to be a drain on user productivity or an obstacle in the road to future product development. If you look at it instead as a valuable opportunity to efficiently make huge gains in system quality, then you’ll really start to benefit from all that deployment has to offer.

Got a deployment story you’d like to share? 🙂

Product Development Is Not My Thing

flowchart of agile software product development
It’s been about eight months since I started working for a software product company. Prior to that, I’d spent a lot of time writing software for various audiences – but always for internal use. At my current gig, I’m not working directly in software product development – my role is quality assurance and testing.

I’m not directly influencing the software product output. I am influencing primarily the software development process which causes that output – by finding bugs, finding process problems, and recommending improvements. It’s an internal support service role.

Probably my most natural role in technology is in the areas of support and service. That can mean many things, and in the case of my current job role it means I provide a service to help ensure high quality in the product that the company sells. I’m not sure if I would want to work directly on the product side – even though that’s the revenue generator, it is also the area where the work can get bogged down in a lot of details that don’t necessarily lead to creative solutions to technology problems.

True, in an ideal world product developers would always be primarily focused on innovating and providing the most creative solutions, but in the end the constraints of working within a product framework mean there are a lot of limits on what can be done. Every decision must keep in mind not just the problem at hand, but also the generalized problem that the anticipated product audience has. There is naturally a constant struggle to retain innovation.

When you work directly in service or support, you also have these sorts of constraints but the decisions and actions you take have a little more wiggle room because they aren’t getting baked into the product. There’s a little more chance to be flexible, find new and promising solutions, and move freely.

But of course that only matters if you find ways to take advantage of that flexibility.

Don’t underestimate the value of software bugs


Finding software bugs

[Tweet “Bugs are about making things concrete, specific, and known.”]

Some people don’t like software bugs, but I think they’re awesome.

After all, how else can you tell when or if your software works? Without a bug report, it might just be “sort of” working. Maybe it works the way you are using it now but it is going to come crashing down as soon as you veer slightly off the standard code path. You know your software is fragile, but maybe it is WAY more fragile than you ever realized.

Shine a light on the problem

But once you have a bug, then you’ve got an anchor. You know – concretely – that a certain thing does not work.

And around that, you can build a foundation of all the things that you know DO work.

The software bug keeps you centered. It tells you about all the things in your system that are true, and it tells you about all the things in your system that are not true.

How a bug does it’s magic

Does this seem a little idealist? Vaguely touch-feely?

Well, bugs are touch-feely. They are… personal. They ask questions, and force you to ask new questions, and they lead you to answers.

Bugs are about making things concrete, specific, and known. These are not idealist wishes, and you’ll find that vagueness quickly disappears as your list of recorded bugs grows.

Without bugs, no questions get asked (and so, no answers are ever discovered).

Appreciate your software bugs!

The next time your support tech or your progammer comes to you and announces the most awful bug you’ve ever heard of, give thanks – that person just opened an opportunity for you that you couldn’t have paid for even if you wanted to. Embrace the bug, embrace the value.

Celebrate the software bugs you find. You’ll be glad you did, when they pay you with great rewards.