Project Management

Do I have to go home? Great office space makes for a great place to work.

* * * * * * * * * * * * * * * *How would you like to work here?


No, not for the hotel; at the hotel.

My office needs an ice cream truck!

Ah yes, summer is coming to an end, but those ice cream trucks still come around sometime in the early afternoon. Yeah, I typically notice them on a weekend, at home, just when I am trying to read a good book. They are loud, their music annoying at best and they tend to hang around for too long, waiting for kids to bring their parents' cash in exchange for some over-priced ice cream. The music keeps going while they wait. It's really just about impossible to focus on anything till that truck has moved on.

I want one of those to stop at the office. Every day!

Alright, alright, someone is clearly losing it here. This is obviously a ridiculous idea. We cannot possibly even think about taking this suggestion seriously. The noise is disruptive and loud, nobody will be able to get any work done. Meetings get interrupted, people will goof off taking their ice cream breaks. I just really don't get, why anyone would even think about - Wait, stop right there.

I realize, it sounds crazy.

Makin' Pie

Well, must be the season for wrapping up development cycles. As evidenced by other entries (by Alex and Keith) I’m not the only one looking forward to the winding-down of another successful product.

Only our development cycle ended in July, so we’re a few months late. Sue me.

Project Post Mortems

Another couple of days and the current cycle comes to an end: We are indeed releasing the next iteration of a product. Of course it doesn't end there, as most software products don't ever really finish. No matter though, it is a nice time to take a step back, pause and evaluate how things went this time around.

It's time for a post mortem of sorts.

We're 90% Done!

We're 90% complete with X and we'll be done in no time!

We all know it never happens that way, yet we hear it regularly, most of us have said it, and some of us have said it more than once.

Why does this sort of thing prevade software development?

Good software has users

If you build software, manage a project or direct an IT division take a moment to answer the following question: Who are your users? If an answer eludes you, read on.

Good software has users. Understanding this simple statement may make the difference between solving imaginary and real problems. Information Technology, at its core, is an effort to pair technology solutions with domain problems, where a problem may range from generating reports to architecting massive systems. No matter the scope, technology solutions should be informed by the needs of users.

Visual C++ 2005 lessons

Its been a while since my last post, but I wanted to kickoff this blog column, of codesnippers, with a project, around C/C++ ... To begin, I'd like to introduce the tools I'll be using, Visual C++ 2005, and leave it up to the readers for a possible project. I have an idea, I'd like to attack at the end of the post.

My last blog was about reviewing my favourite cross-platform C++ UI, wxWidgets. Reading up on my peers on this site, I don't see too much C++ talk. So I figured, I'd start with an intoroduction on Visual Studio 2005 (aka Visual C++ 8.0).

Despite it being an evil Microsoft Empire product, its really not all that bad. If anyone is serious about being a software engineer, C++ knowledge is essential! And great C++ knowledge can take years to master. To start in this journy, I'd like to begin with an introduction:

A guide for changing programming languages

Many projects will encounter a point of frustration with some aspect of Information Technology architecture and developers may clamor for a new technical solution. Changing programming languages may involve a significant rewrite of the software, which is a bad idea most times. However, if you are faced with a compelling technology how should a Project Manager approach the transition? Two personal examples may shed some light on the decision whether or not to change programming languages.

Agile Methods need a different mindset

I came across a great article today from Agile Project Planning called: "Do agile software teams make more mistakes?" and he points to the obvious answer of "Yes!" But then he goes into a detailed explanation describing that success comes about quite often because of failure, not in spite of it. True points all and I completely agree, but I'm a bit more pragmatic about it.

As a advocate of Agile Methods, I agree wholeheartedly agree with the idea of fast, tight loops to get customer feedback, design reviews, code reviews, error correction, etc, etc. But in most development, the customer already has a rough idea of their goal and it's your job to figure this out. If you have an excellent requirements gathering/digging team, you probably already have a list of these, but it's nowhere near complete regardless of what the percentage next to the task says. There will always be more that you have to do because of incomplete requirements, unclear requirements, misunderstandings, new customers, etc.

It's an iterative process, so your development should be too.

For example, I live just outside Washington, DC and grew up outside of Chicago. When I drive back, I essentially get on I-70 Westbound, turn northeast at Indianapolis, and turn West again at the appointed place. Little thought is involved because the path is clear, I've driven it quite a few times, and it's major Interstates almost the entire way.

On the other hand, if I go to visit the highly esteemed Duane (a fellow CodeSniper), it takes a bit more effort. I've only made the drive to the area a few times, there are more turns involved, there are state highways involved, and it's to an area that I'm less familiar with. Therefore a completely different mindset is involved:
* I plan the route by looking at the map in advance.
* I keep an eye out for landmarks to mark my progress.
* I watch the odometer and clock to compare actual driving time against my plan.
* And as I get closer, I give him a call to get any last minute changes, detours, etc that might affect my decisions.

When you know exactly where you're going, how to get there, approximately how long it should take, and you've done it numerous times, a waterfall method might work.

If you're unfamiliar with the destination, the route, the effort, and you've done it less than ten times, you need ways of evaluating your progress, establishing baselines and adjusting your route as you go.

This is why I use Agile Methods... because even when I "know" the route, there are a million things that can happen along the way.

Are bad Requirements our fault?

Over the past week or so, I've been reading Marcus Buckingham's First, Break All the Rules. I caught him at a conference last year and finally got around to picking up both of this books, so I've been looking forward to this.

Anyway, I'm approximately half way through it and while I was reading this morning, I was struck by something. Let me quote:

Conventional wisdom asserts that good is the opposite of bad, that if you want to understand excellence, you should investigate failure and then invert it.

He goes on to support this by pointing out that we tend to study things if we want to prevent them: student truancy, drug use, etc, etc. And I found this interesting when applied to some of my recent projects. Everyone tends to focus on "what went wrong and how do we fix it" instead of "what went right and how do we do more of it?"

As is common in the software world, we complain quite a bit about not having a specification. We talk about it to anyone who will listen... and I was actually doing it this morning. Maybe we need to change our perspective a bit. As John pointed out in his recent post, most of our customers and even we take things for granted in how they should work, how we perceive the world, and what we expect from our people and our tools. When we are working with something as intangible and complex as software, we need to focus on making things a bit more tangible and descriptive for our users. We have to make sure that they can understand some of the key things... not *how* we're doing something, but what the tradeoffs are.

I believe that we need to educate our customers on not only what is possible, but what is impossible given their constraints. Not only could this help clarify requirements, but it might completely eliminate silly requirements like "Build an auction system on par with Ebay".