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. :)

Mental Learnings

In this post I try to summarize what I learned from the final part of Thinking Fast and Slow. I've already written two posts about the subject (here and here), but I still want to share something about it (also I can then later refresh my own memory about these things).

Two Selves

Our mind works in two modes. There's the experiencing self that sits at the drivers seat. Everything that happens, happens to this poor fellow. Then there's the remembering self. After experiencing self has done it's part, remembering self decides how the event will be remembered. And surprisingly, this remembering self makes most of the decisions regarding your future.

When we experience something, we don't really remember the whole event. If you for example think about your past work week or last summer holiday (for Finns that might be many weeks), you don't remember all of it. You remember some moments. And actually if you experience something for a longer time, you don't really pay attention to the length. These two things are called duration neglect and peak-end rule. The book offers painful operations as an example. Afterwards you can't tell if you were in pain for 60 minutes or 80 minutes.

Suppose you go through painful procedure that lasts 60 minutes. Then suppose you repeat the same experience, but after 60 minutes you get painkiller and the operation lasts for another 20 minutes. If participants in these two experiments were asked which one they would repeat, majority would select the latter one. Although this means 20 extra minutes of pain! Are they mad? No, remembering self just doesn't care about the length (nor apparently about the suffering of experiencing self...)

Tip for presenters: aim to have some neat moment in your presentation and try to end with a bang. You will be remembered. Unfortunately it's easier said than done. Here's my attempt from this year's Scan-Agile.

Sure Thing vs. Gamble

People dislike risk in most cases. In lotteries, people prefer getting sure but smaller gains versus bigger ones with some risk included. But situation depends a bit on how you frame it. 90 percent survivability rate sounds good. 10 percent mortality rate doesn't sound that good anymore. And if you say that 100 persons out of one thousand WILL DIE, that sounds just super bad. Unfortunately we humans are not immune to these framing effects and political and jury decisions can be influenced bending the words properly.

 

Although people are generally risk averse, there are times when they are willing to take risks. If you are faced with only bad options, you will take risks. Another case is lottery or some other possibility to get a highly improbable big gain.

On the other hand when you are almost sure you will get something (95 percent probability), you are willing to settle for something less if you can get it for sure. Who Want's to Be a Millionaire works like that. You can anytime walk away with some much smaller price. This price increases as you get further in the game. And the bigger the sure price gets, the less tempting it will feel to take the risk of losing everything.

Then an example about possible losses. People don't just buy insurances; they buy ease of mind. Even if there's only a very small probability that your house will burn down, you are willing to get an insurance against that.

Finally, the outcome of an event is not everything that matters. The previous state plays a big role too. If two people have equal pay today you shouldn't simply assume they are equally happy about it. The other one might have received a big salary raise recently. The other one might have been dropped from a higher position and hence suffered a salary cut. Probably the first one feels joy, but other one might be looking for a new job.

I've covered only some things from the book that I found interesting. There's plenty of more. I can truly recommend reading this book. It makes you see things differently.