Defining a baseline is one of the best things you can do if you want to deliver things fast. It sounds like a pretty simple concept, but the truth is that many software engineers do not understand that there should be a baseline in everything.

I personally try to find and impose baselines in everything I do, as this helps me improve work products. This happens in a pretty simple way – the baseline “forces” me keep track of modifications I make and at the same time it makes me more responsible about them. Let’s review some use cases.

Product Management

Let’s imagine that you are working on a prototype for a new product. And you have a lot of ideas. And you get a lot of feedback. With every iteration, the prototype becomes better and better. Yet, over a long week-end, you come across a stunning discovery. Many “improvements” so far suddenly don’t feel so good anymore, although all of them seemed great when they were first suggested.

This happens because there is no baseline. Having a baseline allows you to say “this is version one”. Everything we do are improvements to version one. Our concepts are well defined. And everything we do must target a specific concept. Once everything is settled and analyzed, a new baseline is set. And yes, we use versioning in product management as well.

Without doing this, you end up with “improvements” that bring some changes to the concepts, but without delivering more.

Software Architecture

Same thing happens in software architecture. I’ve seen guys working for weeks on a design that got changed 80% immediately after it went into production. This happened because they didn’t actually control the design. Any new iteration was much like a different animal. In fact, the criterion they used when assessing the design as good was the time spent on it.

Technical Support

It might sound strange, but it’s vital to set a baseline when your customer opens a case. This baseline is what you know and how you start. Without this baseline, one can solve countless collateral issues and miss the original problem. This scenario is the optimistic one, as most of the times nothing gets solved and the customer tends to complain more about lots of apparently unrelated issues.

Coding

I know lots of people who love nice code. In fact, they get pretty paranoid about the code they write. And as much as they love their own code, after six months or so they are willing to throw everything away and write it all over again, in a “much better way”. And this scenario can go on forever and ever. Even in this case, the problem is the baseline. Since they do not see the code as a deliverable, but as a means to do something, they tend to forget that it’s the result that matters the most, and the code is just a tool.

Software Testing

Performance testing is a good example. As a matter of fact, performance testing might get messy, especially when it’s done in the cloud. The SUT (System under Test) is distributed; the test conditions cannot be easily replicated due to independent factors and so on. Still, most test results do not include the baseline, or they fail to identify the correct one. For cloud performance tests, the baseline is always the test execution with a single test client and a single node on SUT.

Without this baseline, the testing session is kind of useless. It provides information about how well it went in the conditions described, but fails to answer more important questions such as: How is our system scaling? Is it limited by hardware? Did we get the test conditions right? Do we have predictors for performance? What can we actually change?

Baseline Early!

I can give you tens of examples when failure to identify the baseline leads to messy results. The baseline basically helps your iterations become more efficient.

However, there’s also something good about software engineers and baselines – once the first one is set, they are pretty good on moving forward with the following ones. This may happen because they are used with versioning 🙂

Still, it’s usually a nightmare to decide on the first one.

Non-tech people like marketing on the other hand are not so familiar with versioning. That’s why it is even harder for them to pick the baseline and iterate properly. For example, I’ve seen pretty good concepts that required only a few changes. After applying these improvements, I was shocked at the result – the improved version was totally different to the original one, which should have been the baseline and close to acceptance. Eventually, problems are solved, but with major overhead and wasted resources.

If you want some advice on how to pick the baseline, just let me know.