Archive for the 'strategy' Category

15
Dec

The open source question

By Don Ardonio 10 Comments
Categories: development, leadership, management, software and strategy

I’m tired. Tired of hearing yet another big bozo speech about how we will move to open source and how that will magically reduce our costs and make our software better.
Gentlemen (and those few ladies who end up reading this), behold, a couple of reality checks

1. Open source is not free
Contrary to popular belief, open source comes at a cost. Unlike commercial packages (full software, or libraries) the cost here is not tied to the initial cost of acquisition (either as a license fee with or without a support contract). The true cost of open source hides at a deeper level. The place where it still costs money is a cost of integration. Even though the idea of open source is that there are a whole slew of people working on it and that the community will be the best support group ever, the reality is that a lot of open source projects are actively maintained by only a handful of people per project. Which generally means that you (the developer who needs to integrate it) will spend a lot of time reverse engineering the code.
The second point where there is a form of (rather indirect) cost attached is in the area of strategy and maintenance. Since this code is created and maintained on a voluntary basis it doesn’t really carry any form of guarantee that it will be maintained and/or evolve, and if it does evolve in a direction that might not be what you wish/expect, there is no sales/account/technical staff to help you out in the migration or to voice your concerns to.

2 The licensing aspect
There is a vast number of licenses out there, making the distinction between all of them is beside the point here. Suffice to say that, in general, there are a number of common themes.
Not everything can be used for commercial purposes, some might require that you submit any modification back to the community under the same license, some allow you to use it as if it were closed source, … . Best to have your legal people look at the license if you are unfamiliar with the matter. Just a point of attention…

In conclusion, yes I believe open source code can make your software better but there is an amount of sanity checking that needs to be done (just as we do with closed source). The questions to be asked are not just a matter of financial or legal cover-your-ass but also of strategy (do I like where this thing is heading?, do I want this vital piece of my software to be open source?). There is no one-size-fits-all answer to these questions, so let us please answer them and do the due diligence.

14
Aug

Embracing failure

By Don Ardonio 3 Comments
Categories: agile, development, management, software and strategy

The most burning question a business generally has for engineers is “when will it be finished”.  They are looking for a specific date and often a specific plan for how you’ll get there. They would most likely be overjoyed if you could tell them exactly at which point in time you will write which line of code. As engineers we have a love/hate relationship with that question. Somehow there is an understanding of the importance, but we are dealing with so much unknowns that we find it hard to commit. It’s in our nature to look at all possibilities and account for a large number complications, even though they may never occur. And then there’s off course always the “give us a clear requirement” catch-phrase we throw back at the business. (truth to be told, we often don’t do a good job in helping the business find that clear requirement, but that’s a different discussion altogether)

To many engineers the request for a date seems unreasonable and shows a clear lack of understanding and appreciation for engineering from the business side. However, if you look at where those people come from it’s not so hard to understand.
When you have to plan a production-type operation you are dealing with a known process. You know every step of the way, probably in great detail. So it’s rather easy to plan. If you know that turning a screw takes 2 seconds, it’s a no-brainer to see that in one minute you can turn 30 screws. It’s very predictable and controlled. And the more detail you get in your planning, generally the more control you’ll have.

Unfortunately, all that is not so much true for engineering. Crafting software is a creative process. It’s about figuring stuff out. Stuff ranging from a vague requirement to the logic that goes into an algorithm. It’s dealing with unclarity and vagueness. Software is often more of a trial and error thing. And the unknown is feared by many as it means letting go of that tight control they had for decades.
The key to engineering is not fearing but embracing failure, and often to try and fail as soon as possible. Many innovations have come after numerous iterations of failure and software is no exception to that rule. Engineers need room to experiment, and you can’t plan for that. You can’t plan (in the typical production way): “let’s fail five times and get it right the sixth”.

All that doesn’t mean that engineers shouldn’t do planning but there’s a different angle to it. Engineers might not readily admit it, but generally if you give them a problem they can make a reasonable estimate. It won’t be accurate per se, but they will have a gut feeling for what it will take. They understand their job and even though they can’t predict every possible failure they encounter they generally can outline an approach in their head and take a shot at telling where the painpoints will be. The key here is that in the end they are still only estimates. They are not the exact science to what traditional managers are used to, only an indication of magnitude of work.
Sometimes though, that simply isn’t possible. The problem might be to vague, the problem space not enough understood, … . In that case I am a huge fan of timeboxing. Reserve a specific set of time to do some preliminary analysis, come up with questions, possibilities, … and present that back to the original requester.

As I said many times before, the job of a good project manager is twofold. First there is the making of a plan, which accounts for both the operational tasks and the more freeform creativity needed for engineers. Second, and more important, is dealing with changes in that plan.

14
Jan

The morning routine

By Don Ardonio 0 Comments
Categories: communication, personal and strategy

I’ve been trying out a new morning routine for a couple of months now. Here’s how it looks.

  1. I wake up around 8:30
  2. I pick up my iPhone and read the mails that were sent overnight by my colleagues from around the world (mainly US)
  3. Mails that require a lengthy answer or research are marked, short answers are sent directly
  4. Get out of bed by 9:00, take a shower, get dressed and walk to work. So by the time I’m at my desk it’s about 9:40

I find that this strategy offers me a few significant advantages over going to the office and start working through my inbox.

First of all, I give my brain a kick start by digesting work related matters straight away forcing myself to get a lot of stuff into memory instead of somewhere latently present in a galaxy far far away. While I’m walking I give myself time to reflect on the information I just received. Those 20 minutes walking are vital since they largely define a plan of action for the day. I draw up a mental list of people I need to speak to, topics I need to digg in, ideas I want to bounce around in a meeting, … . Basically, I’m compiling a to do list on the way to work, knowing I have the latest info available.

Second, and more important, I’m up to speed before I arrive in the office. Our great landscape office is ideal for being harassed every minute of every day, meaning I hardly ever get a quiet 30 minutes stretch to work through some topics (I’d give money for a private office with a door sometimes).

27
Jun

The end of an era

By Don Ardonio 0 Comments
Categories: business, software and strategy

Today has been marked in my calendar for a long time. Today is the end of an era. Today is the last day of Bill Gates at Microsoft.

We all have an opinion on Microsoft and their products and strategies. I don’t care what camp you are in, if you’re totally pro or against Microsoft. There is one thing you can’t deny. Bill gates had a vision and shaped the IT industry.

He had a dream of "a computer on every desk and in every home". Looking at where we stand today, I personally think he overachieved. It’s not just a computer on every desk and in every home, it’s gone far beyond that. And if you want it or not, Bill gates and Microsoft have shaped a large part of this, for better and, most likely, also for worse.

I’m not going out on a "all hail" rant for Bill, but respect is definitely due.

07
May

(r)Evolution

By Don Ardonio 0 Comments
Categories: 2.0, personal and strategy

I came across this post and immediately felt a very familiar sense. It’s something I had been wondering about for a while.

I started noticing on events and various ad-hoc meets that a lot of the crowd I know is also on twitter, has a (couple of) weblog(s), is all hyped up about latest developments in the e-world, … and all in all are probably a bunch of early adopters.

If I compare that to the business reality I live in, I often find myself far away from those people on the technological front (I don’t work in a internet related business, for those who might wonder). In general, my colleagues represent the ‘average user’. What strikes me most about them (besides the fact they rely on internet exploder) is that they still consider the internet as this ‘out there’ thing that by definition has to be accessed through a browser, either on their desktop or on their mobile. Which to me indicates 2 points that need to change before the masses will be ready for things like twitter.

1. The internet is not a set of web pages. It’s a medium to transport digital content of any kind, that can be stored somewhere in that cloud.

2. Out of realizing point 1 follows that you don’t need (just) a browser to access that content. Which opens a lot of opportunities to work with this concept in innovative ways.

Given that people imho will eventually adopt these 2 things, there are interesting times ahead of us…

10
Apr

9 baby’s in 1 woman for a month

By Don Ardonio 0 Comments
Categories: business, management and strategy

Or at least something containing all those elements. This article is all about the question "Can 9 women deliver a baby in 1 month?". In this post and subsequent comments we already brought up that 9 women can’t deliver a baby in 1 month in a lot of cases. Somewhere I said that they may be able to deliver, if delivering a baby only took cpu power. I still stick to that statement, but want to expand a bit on it.

From an engineering point of view, the statement is ever so true. If 1 server can process 100 jobs every day, than 2 servers generally can process 200 jobs every day. (simplification, I know). So 9 women, 1 month, baby delivered.

From a business point of view, the first thing that comes to mind here is: does the return of adding that extra server really justify the investment. A story that makes it crystal clear.
A production plant for a car has an assembly line installed that produces 500 cars of one model every day and has been producing for the last 100 days. Installation of the assembly line cost 50.000k and took 20 days to install, test and be completely production ready. The lines are specific for one car and can’t be reconfigured. Every car sells for 1k. Recently, due to high demand of that model of car, they would need to produce 750 cars / day to fulfill market demand. The expectation is that this increased demand will last for 300 days, after that demand will drop to 500 again. Or put otherwise: there is a loss of 250k in potential revenue every day (or 75.000k over the 300 day period)

There are 3 options here (for simplicity sake). First one is: build another production line to produce the 250 extra cars / day. Option two is to slightly abuse (overclock, speed up, …) the existing line so it produces 565 cars / day. The last option is simply to ignore the higher demand, and keep producing 500 cars / day with the existing system, and work on a backorder. (and combination of the options are not possible)

Let’s do some maths for option 1. It takes 20 days to set up a new system, meaning you don’t get (20*250) 5.000k in revenue. After that you are able to build 750k cars / day, gaining you 250k extra income every day. In turn meaning that it would take 200 days before you paid for your assembly line and the 250k every day becomes bottom line profit. Summarized: installing the new machine cost you 55.000k (50.000 install + 5.000 in lost revenue) + 220 (20 install + 200 to repay the machine) working days before it makes you 250k/day profit. (to all you economical gurus out there, I know this is technically not entirely correct but I’m trying to get a point across). Since the expectation was that the increased demand would be 300 days you would effectively have profit for 80 days (300-220), it means you’ll get 20.000k (80*250) in bottom line profit and are stuck afterwards with an extra assembly line. Your main line would produce you a profit of (300*500) 150.000k.
Profit and result after 300 days: 170.000k + 1 unused line.

Now consider option 2. Your assembly line cost 50.000k and gets you 500k every day. So you’ll have payed it off after 100 days, in our example this means that your line brings in 500k to your bottom line every day. The speeding up of the line would cause the factory to be closed for 10 days but would get the production speed up to 565 / day. The only cost you’d have is a new software roll out on the robots.Some numbers.
Closing down for 10 days means missed profit of 5.000k (500k *10). However, it leaves you with 290 days (300 days of high demand - 10 for installation) of production at 65k extra profit per day. Or: an additional bottom line profit of 18.850k (65*290), and no unused machinery to take care off when the high demand is over. Your main line would make profit for 145.000k (290*500)
Profit and result after 300 days: 163.850k + nothing extra to maintain

Option 3 is easy on the maths side. You get 150.000k (500k * 300). Your machine was paid off, so all you get is the bottom line of 500 cars / day. 
Profit and result after 300 days: 150.000k + nothing extra to maintain

I would personally favor option 2. Even though there is less immediate gain, you are not stuck with costs associated to having that machinery around (even unused machinery still costs, in the sense that it takes space away for machinery that could be used). Which sounds like a better long term plan.

To go back to the 9 women theory, and the point of this article. Yes, 9 women can deliver a baby in 1 month in certain situations but (big caveat) you’re stuck with 9 women afterwards…