Building a New Product

As my opinion about perfect team structure has developed during the past years, so has my understanding of how awfully many different things need to be considered when building a new (desktop) software product.

As a coder I used to think that a random idea is a good starting point for a new feature. I still believe that making a crude and fast proto is a good idea, but there's maybe even better way. Before writing any code, make a sketch. Before implementing any functionality, test the idea with a real customer if possible. Then make variations to the design and iterate again. Do this for a while and you have less code to maintain and better understanding of what you maybe should be doing (Lean Startup and Lean UX).

Instead of just copying files between different computers, you might want to set up a version control system. There are many providers, but I can easily suggest Git. It's free, relatively easy to learn and so widely used that you can get help and skilled Git users easily.

"Well written code is its best documentation". I partially sign this statement but not totally. Useless comments that get out of date are just useless. But there might be general design ideas like what kind of inputs and outputs are expected and how different parts of the product are supposed to communicate together. Usually these higher level characterizations don't change much even though classes and modules can have much shorter life cycles. So some amount of (design) documentation is nice.

I like to promote test-driven development, because then you get a nice set of unit tests and presumably your life will be much easier later. It's like an investment into the future. Of course before you can write tests you need to implement a test framework. Fortunately for many modern languages these are often easily available. But if you are dealing with more exotic playground, you might need to invest a bit more time and effort. Never the less, having a unit test framework is an investment you seriously want to make.

It doesn't harm if testing and test automation is given a thought already at the design phase. You might want to have a tester involved.

If you are not intending to make your product open source (which is of course ok too) you should maybe build some kind of licensing system. There are many possible business models and maybe it also depends on if the users are expected to have internet access or not. But it's also an aspect to keep in mind.

Last but not least, after developing the product for a while you might remember that there should also be a way for the users to install the software. And it might have some prerequisites and dependencies that should be fixed before the happy user is able to start your product. You need an installer (WiX, NSIS, InstallShield). And if you haven't done that yet at this stage, you probably also want to set up a Continuous Integration system.

In addition to these, there are many more useful practices (coding and documentation conventions, manuals, 3rd party libraries, etc.), but I think I'm done here. The main point of this post was that there are really many things to consider when kicking up a new product. And even if you implement these it doesn't really guarantee anything yet. But at least you are not failing because you missed these things. :)

(Release) Version Control

During my holiday I noticed that Scaled Agile Framework had been updated to version 3.0. I did watch the short update video by Lean Samurai (which was nice and compact), but I haven't really had time to get familiar with most of the contents yet. Some positive first observations include dropping Hardening out of the HIP-sprint (nowadays only Innovation-Planning) and making an attempt to include also strategy into the big picture. Although I like IP more than HIP, I don't really like dropping the shippability from the PSI. I'm glad that separation between development and releasing is still there. Maybe I will learn to like Program Increments.

But the topic I was about to write today is Continuous Integration. It has now been lifted to the big picture to get the attention I think it really deserves. Scrum doesn't offer engineering practices (XP does), so companies should amend their processes with some additional common agreements. Let me now write down some clichés that have some valid points behind them:

• You can't scale crap.
• You can't go fast if you carry a lot of extra.
• Integrate often.

Well, one could consider these also as plain facts. But the first two are more or less related to good coding practices and craftsmanship and staying Lean. Also keeping the technical debt as low as possible helps going faster. The last bullet is related to version control and software production.

We are applying the stable mainline pattern. To get a more thorough explanation on this please check here or here (again I find good stuff and it has Mr. Kniberg's name written on it. That guy is a wizard!) We use a rather well integrated set of Atlassian tools. Atlassian Stash as the basis of our repository management accompanied with Atlassian Bamboo crunching the builds. And they both communicate nicely with JIRA. (While looking for some nice pictures, I bumped into this video about making a demo integration. Maybe worth watching.)

When the code changes are checked in, the builds start automatically. They include running the automated tests (unit and integration), followed by more wider range system level tests if everything went well. Good changes are blessed with a nice green color, but any breaking changes result in an ugly red color.

In Bamboo you can configure the plans to make builds for all new branches automatically. This makes the creation of release branches handy (compared to some other CI frameworks where you need to configure a new build for each new branch.)

Finally, the big dilemma when we make releases. We branch the release from the trunk. This is communicated well in advance to all the teams and developers. But after we make the branching, we don't allow any more changes to the code. Stash offers a handy way to do it from the branch permissions. To be more precise, we do allow changes, but they need to be made via pull-requests and approved by the System Team.

My dilemma here is that I'd like to believe in people. I believe most of the restrictions usually hinder development. But then again, I believe many people are aware of the term feature creep. It's easier to fight it if you don't have a way to make changes. And the obligatory pull-requests have a built-in code review which usually helps improve the general code quality.