Last night I was bored, and my girlfriend didn’t like me bugging her. I needed something to do, so I decided to create a clone of the classic video game Minesweeper.

Minesweeper’s Wikipedia page reads the following: “Minesweeper is a single-player puzzle video game. The objective of the game is to clear a rectangular board containing hidden “mines” without detonating any of them, with help from clues about the number of neighboring mines in each field.”

One hour and one hundred lines of code later, I finished a crude but functional version. Then it got hard, and I lost interest. Later, I thought about the work that needs to be done, to turn this project into a business. Creating software always seems easy, but it is good to realize how much difference there is between a prototype and profitability. Here we go…

DEVELOPMENT

Hard core engineering – I assumed that when a game starts, the mines are placed at random. This assumption was too simplistic. When mines are placed at random, they can be clustered together. This gives a lousy gaming experience. Mines should be spread out evenly. Here we strike an engineering problem.

Missing functionality – If you step on a mine, it blows up. Which is one way to lose the game. You should also lose the game when you mark more mines than there are actually hidden. My version of the game does not support this. It would also be fun to play against a clock, or have high scores. More development is needed.

Refactoring – In the source code, I refer to mines as bombs. To prevent confusion in future development, we need to refactor this. There is a bigger problem. I developed the game as a Windows application. Which is obviously wrong. We need to port the software to a mobile platform for iPhone and Android.

Quality assurance – The game works, I think. I played a few rounds, and have not found any bugs. To be sure we don’t ship buggy software, we need beta users to test extensively. We also need to write unit tests to prevent bugs creeping in during further development.

User experience – In the Windows version of Minesweeper, you navigate the mine field by using your mouse. In my version, you need to manually enter coordinates, and push a button to mark or expose a cell. This is too crude to be fun. The user experience needs to be sheer joy. Currently it’s not. Even I don’t like it

MARKETING & SALES

Branding – Our game should not be named Minesweeper. We need a new name that stands out from the competition. The game needs its own back story, like Angry Birds for example. This story needs to be perpetuated throughout the software, by the consistent use of logos, graphics and sound effects.

Distribution – Now that our game is finished, we need to make it available via the various App Stores, Play Stores, gaming websites and wherever else we can distribute. Without a doubt, we need to make a few round trips to the development phase, in order for the game to be accepted on these platforms.

Promotion – Once the game is ready for distribution, we can promote it on a website, Twitter, Facebook and via other social media. Ideally we want the software to go viral. That idea of keeping high scores, and comparing high scores with friends was not a bad thought. Back to development, once again.

MANAGEMENT, FINANCE & LEGAL

Team work – I cannot do the above on my own. I don’t have the skill, nor the time. Graphic design is a profession, so is distributing the game through the various channels. We need to find freelancers who can help out. And set up a virtual task board (like Trello) so we can coordinate the various tasks.

Liabilities – With money going in and out, we created two new ‘problems’: responsibility and liability. With any luck, the Terms & Conditions and privacy statements are provided by the distribution channels. We do need a bookkeeper, a bank account and possibly a registration at the Chamber of Commerce.

 

This mental exercise made me think about all the different aspects that go into creating a successful business. And how difficult it is to get all the pieces right.

Iedere winter wordt de klimberg Monte Cervino in Bergschenhoek omgetoverd tot een Drytool winter wonderland. Aan de binnenkant van de berg kun je sportklimmen, terwijl aan de buitenkant tientallen Drytool-routes gebouwd zijn.

Drytoolen is een kruising tussen sportklimmen en ijsklimmen. Een Drytool-route is eigenlijk gewoon een sportklim-route. Je klimt ook gewoon op je klimschoentjes (*), en je mag gewoon je handen gebruiken om omhoog te komen. Echter, al snel kom je grepen tegen die heel klein zijn, of heel ver uit elkaar zitten. Dan wordt het echt Drytoolen, tijd om de ijsbijlen te gebruiken.

Een Drytool route is gebouwd uit normale klimgrepen, die je kunt vasthouden, heel kleine aluminium grepen waar je ijsbijlen in klemt en blokken hout, waar je lekker in kunt meppen. Maar let op! Drytoolen is een subtiele aangelegenheid. De plaatsing van de bijlen komt heel precies. Voor je het weet gaat je bijl zwieberen, en val je naar beneden. En dat maakt Drytoolen juist zo bijzonder en waanzinnig leuk.

In de winter, buiten, met ijsbijlen zwaaien is niet alleen voor stoere jongens. De dames waren op de recente Drytool-wedstrijd goed vertegenwoordigd. Drytoolen is leuk voor iedere sportklimmer die wel eens iets anders wil proberen.

De Drytool-routes bij Monte Cervino blijven tot maart 2015 hangen. Je hoeft geen eigen bijlen te hebben, deze kun je lenen bij de bar (**). Ook hangen er al t0uwen om te top-ropen. Neem wel een warme jas, handschoenen en je helm mee. Kom je ’s avonds, vergeet dan je hoofdlampje niet.

Lijkt het je leuk om een keer te Drytoolen, maar ken je niemand die met je mee wil? Laat het mij dan zeker weten. Wij klimmen iedere vrijdagavond, en vinden het altijd leuk om nieuwe vrienden te maken. Mail mij gerust op florian.hoornaar@gmail.com.

(*) Marianne van der Steen, 1 van de routebouwers, schreef mij na het publiceren van dit artikel dat het klimmen op klimschoentjes een uitzondering is. Normaal gesproken klim je op stijgijzers. Ze stuurde mij ook twee filmpjes die het bekijken waard zijn.

(**) Er zijn momenteel tijdelijk even geen ijsbijlen aanwezig. Dus neem deze toch zelf mee, leen ze van iemand, of bel van te voren op en informeer of de ijsbijlen al weer terug zijn.

I love clients. That is, clients who pay their bills. Admittedly, I once accidentally sent an invoice, even before the project started. Of course the client didn’t pay. I like to call this an exception. If the invoice is justified, then the client must pay. The full amount, on time.

In my years as an entrepreneur, I luckily had few clients who didn’t pay. Two times a client went bankrupt. I lost a few hundred euros. They lost their business, their house and everything they own. I feel sorry for them, and wish them well.

Grimmer, I will never forget a client who ordered a project, fully aware of the costs. And upon delivery, he simply did not pay. There were months of battle. We even went to court. But by then, his business was bankrupt. And so were we, almost. He started a new business as if nothing happened. It made me angry and sad, to have worked hard and with passion for him. In hindsight, he was nothing more than a thief. Not paying bills is a disgusting practice.

I have clients who do pay their bills, but always late. To me, this behavior is plain weird. I offer software as a service, on a subscription model, billed every single month. What reason could there be to stretch the 14 days payment term? Are you that strapped on cash? And if you’re doing that bad… you’re at the wrong address. I develop software, I am not a bank.

I have a client who actually negotiated a longer payment term. And he pays. Always. The full amount, on time. I love him. I like to emphasize negotiated. He asked for a longer payment term. He didn’t just take. Taking without asking is stealing, or at best, impolite.

When clients don’t pay, they need to be chased. I don’t like that. In the past I used to make phone calls and ask clients when they would pay. When it comes to excuses, companies can be as inventive as the average sixteen year old. Calls always end with some false promise. So I stopped calling. It’s not helpful, and it drains my energy.

Luckily, with a subscription model, there is a solution. For example, when I don’t pay my phone bill, the phone company disconnects me. I think that’s fair. So, I do the same. I disconnect clients who don’t pay their bill. In this way, they cannot use my software until they start paying again. I find it awful to disconnect clients, but at least the pain is shared.

Now, I have one client who doesn’t mind being disconnected. They don’t use the software, they don’t pay for it, and that’s exactly what they want. This seems clever, but to me, life doesn’t work that way. The monthly subscription fee is based on an agreed contract period. And that contract period must be served.

I feel that giving a client financial slack (e.g. letting them out of a contract or allowing longer payment terms) would be unfair. As self-serving as it may sound, this feeling of fairness is exactly the reason why I will not simply cancel a contract, and will to go to court. Especially when I see that other clients do make a effort to play by the agreed rules.

When I propose a project to a client, I like to quote fixed-price. Whether it is for implementation services, or for software development.

There are exceptions of course. last week, I did some work that I billed by the hour. It was completely unsure how long I would need to complete the project. I promised the client to work with her for a day, and then we would see how far we got. Billing by the hour was the only way to go.

There are benefits to billing by the hour. There is no risk for me, since all hours are paid. And there is more flexibility for the client. From a sales point of view, It is also easier to ‘milk’ the client. Which is a tactic consultants use liberally. Luckily, I am not a consultant.

When a client asks me to do some work, it’s up to me to make an estimation. Rarely does a client have any idea how long a project will take. After doing the work I do for years, I at least had some practice estimating projects. Being the more experienced party, I feel responsible for making estimations, and setting predictions.

Apart from the soft touchy-feely moral reasons, I have a few practical reasons for quoting fixed-price. First of all, the client doesn’t care about hours, he wants his problem solved. And as long as the problem gets solved, the client is happy. This gives me the freedom to execute the task as I see fit. This is especially important when clients ask me to create enhancements to my software. This freedom, allows me to make additional product changes in the project’s slipstream, or implement the requirements in such a way that I can build on it later. This costs me more time, but the client doesn’t care.

When quoting fixed-price, I also set a fixed delivery date. This gives me complete freedom to work when I want, where I want. The client couldn’t care less if I work during the day or at night. From my office, my house, or a mountain cabin in Switzerland (yes, this happened).

Obviously, when the quote is fixed-price, the specifications should also be fixed. There are three pitfalls with fixed specifications. First it is hard to be strict, but you must. Whenever the client wants to change the specifications, tell him it is not possible, or will costs more. This is hard to do, but an absolute necessity. Doing this serves your benefit, the relationship, and thus the client herself.

The second pitfall is the client’s (professional) maturity. When quoting fixed-price the risk is with me. Which is fine if I have a reasonable control over all the variables. The client is a big variable that I have very little control over. So it is best to eliminate the client by not having to rely on him. If the client has to give input, then facilitate for this in the quote. By raising the amount, that is.

The final pitfall can be easily circumvented. I have rarely seen a fixed-price quote work out well for large projects. Quoting fixed-price only works for a maximum of four days work. If the project is larger, quoting fixed-price is akin to Russian roulette. The solution is simple: break up the project in smaller chunks.

I am very happy with fixed-price quotes (as are my clients). Luckily for me the conditions are right. I have been doing this work for a while. Compared to the client I am the expert. I am fairly good at estimating. And the projects are always small.

My hobby is mountaineering. In my spare time, I climb mountains.

The classic answer to why people climb mountains is a quote from the famous mountaineer George Mallory: “because they are there.”

I don’t climb mountains just because they are there. To me mountaineering gives a sense of accomplishment and mountaineering is fun.

Not everyone understands my hobby. Some only see suffering. And these skeptics are partially right. Suffering is an essential component of mountaineering.

To me, the challenge in mountaineering is to strike a balance between fun and suffering. Fun should outweigh suffering, and suffering should be temporary.

Like anyone, I don’t want to get injured, permanently disabled or killed. That is more suffering than fun. So much that suffering turns into harm.

Luckily our bodies and minds have evolved to protect us from harm. It lets us experience fear. Fear is a clever evolutionarily trick to keep us safe and alive.

Not all fear is justified. The main challenge in mountaineering is assessing whether the experienced fear is rational or not.

Irrational fear makes life boring. Or worse, it paradoxically instigates panic, which is downright dangerous.

Rational fear is helpful. It prompts us to lower risks or take precautions in case things go wrong. For example, by being extra careful, or adjusting our plans.

Distinguishing between rational and irrational fears is a skill that requires practice, but when mastered it is a life skill that transcends mountaineering.

I find that mountaineering makes life more fun in general. Whether it is in the mountains, in my private life or in business. That’s why I climb mountains.

I think Edmund Hillary, another famous mountaineer, was spot on when he said: “It is not the mountain we conquer, but ourselves.”

Do you dare to join me?