Tabata Clock

We are pleased to release our first Windows Store app free and without advertising.

Tabata Clock provides clear Exercise/Rest intervals for your Tabata training at home. We look forward to your feedback.

Book review: Management 3.0

A lot of management or process books discuss what has worked in the past for the author with the implication that it will work for you, too. Not Management 3.0 by Jurgen Appelo. His main theme is that software development is hard, complex, and chaotic. There are too many variables with too many unknowns. Not only would what worked for him probably not work for you, but what used to work for you may not work anymore.

Because of this chaotic environment, your best bet is train and empower your team so that their judgement can find the best path. It is hopeless to try to micro-manage them. This book is the author’s attempt to train and empower you. He does not tell you what to do; he gives research and information for you to figure out the best combination for your particular situation. He discusses his research into the various aspects of software management – ideal team size, how to motivate, proper amount of empowerment, etc – so that you can use what you think is useful.

While the subtitle is ‘Leading Agile Developers, Developing Agile Leaders,’ this is not a process book. He discusses Agile, uses it as examples, and continuously discusses how the manager can achieve Agile principles. However, the book is about managing and the ideas should be just as useful in a Waterfall office.


Ode to the Change Request

I’m trying to figure out why anyone would call software defective that perfectly executes the requirements. What I think is that people associate defect fixes as being free and quick while change requests are charged and require lots of paperwork. Thus they want to classify everything a defect.

The reason that defect fixes (and here I am using my definition of ‘defect’ as being that which does not meet requirements) are usually quick is that we already have requirements and the code is already written. We know what to do and it is already mostly done, we just have to fix it.

A change request is not usually quick because

a)      we don’t know what to do. We are not the ones talking to the customer. Besides, we have to cover all exceptional cases. Also, most change requests are inconsistent with the rest of the application and basically wrong. We need to discuss it. I’ve found that in the cases where the situation is intuitively obvious and no discussions are needed, somehow QA comes up with a different understanding and we go around in circles over whose understanding is more intuitively obvious. Besides, we need documentation for traceability. This documentation does not need to be an epic novel, just enough to list the requirements.

b)      The code is not written. New features require new code which takes longer than fixing existing code.

None of this magically goes away by calling the issue a defect. If there are not written requirements concerning the issue (for whatever reason) then we need written requirements made. Simple as that. If there used to be written requirements but no one can find them, then new requirements covering this issue need to be made.

If we don’t want to charge the customer, then let’s not charge them. We don’t have to charge for CR’s. In fact, the overhead of justifying every hour far outweighs the revenue received for the minor CR’s. I don’t understand why we nickel and dime our big customers anyway. We should be doing this stuff as a matter of routine as part of the maintenance agreement.

Let’s imagine a scenario where the customer thinks the functionality should change for a particular scenario that was not covered in the original requirements.

We could a) call it a defect, or b) call it a change request.

Imagine a) call it a defect. We admit our software does not do what it is supposed to do. Our programmers are sloppy. Our QA apparently is incompetent. We apologize and humbly ask for forgiveness. The customer wonders if there are less idiotic vendors to deal with.

Now, imagine b) call it a change request. We explain to the customer that while this scenario was not considered, it is very common in software that once a new feature is released that new situations are discovered and that we would be very glad to discuss it with them. While discussing it with them, we point out how related areas might need to change and some risks involved. We also make some suggestions so that they know all their alternatives. An agreement is made on how the new scenario should behave and documented so that there are no misunderstandings. A service pack is released a month later to address the new scenario. Of course, all of this was at no cost to the customer as part of our comprehensive service. The customer is glad to have partners who understand their business so well and know that there is no one in the world that could possibly replace us.

Change requests are our chance to shine. It is our chance to get face time with the customer and be their partners in planning their business. It is our chance to show the value we add and to actually add value. Let’s not miss the opportunity.


Most people think being a good teammate is to help out others on the team. That is just half of it.

No one in sports thinks a ball hog – someone who once given the ball tries everything in their power to score themself and never passes to anyone else – is a good teammate. Yes, helping others is good but you must also be willing to ask for help yourself. If you do not utilize the skills and knowledge on your team, then what is the point of you being on the team? Just so that they can benefit from your brilliance?

 Even when you do not necessarily need help, it is always good to get a second opinion or bounce an idea or two. By using your team, it becomes a better team.

Let’s Actually Deliver!

The whole purpose of software development is to deliver working software, so I am continually amazed how many people in the process do not want to deliver.

  • QA complains about every little bug
  • UAT complains about every little bug
  • Customer complains about needing training

Apparently anything less than perfect software is not acceptable by these folks.

Sorry, guys. Perfect is going to take awhile. In the meantime, why don’t you take this release which is miles better than the previous?

Perfect is the enemy of the good. Often the cost-benefit of perfect shows that it is not worth it. Spending days of programmer time to save some admins a couple of seconds is value destroying.

Even if you spent the time to get to perfect, you will find that the definition of perfect has changed. Look at Microsoft Word – 15 years in development comprising hundreds, if not thousands, of programmer-years and still not perfect. Of course, the current version would have been seen as spectacular 15 years ago, but today people still find things to complain about. 

Duke Nukem Forever fell into this trap – trying to be the perfect game when the definition of the perfect game constantly moved.

The criteria should be, is this release a step forward or a step back? If it is forward progress, then deliver!

Types of Problem Solvers

I’ve run into these types:

  • Satisfizers
  • Maximizers
  • Optimizers

Satisfizers stop after finding an acceptable solution. Some do it because they are lazy – “I was asked to fix the problem and this spagetti code fixes it.” The others do it out of egoism – “I came up with this wonderful solution and there could not possibly be anything greater than my genius.”

Maximizers latch onto one criteria and knocks it out the park, totally ruining all the other criteria. Does the solution need to be flexible? “Great, lets have a meta-data driven solution with 3 ways of indirection! Not maintainable or high performing? Not important!” Sometimes I think these types think cleverness is an important criteria – one that needs to be maximized. 

Optimizers carefully consider multiple alternatives. They weigh the pros and cons of each to find the one solution with be the best combination of factors. Of course, this takes some time. And actually considering the cons of their ideas means facing their own imperfection. I can see why few do this.

What have I missed?

Maintain Pressure

Intensity is the price of excellence. 
– Warren Buffett

In The Snowball, Buffett makes this statement many times. And author Alice Schroeder makes clear that price is paid two ways – by Buffett devoting almost every waking moment of the past 60 years to making money and by those who have to work with him. Buffett is compared to the sun – nice and warm from a distance but you don’t want to get too close.

While we don’t want to be at Buffett level, excellence requires intensity. And intensity can only be maintained in an pressurized environment. Even if someone has inner-drive, it is no good if no one else will work with that person. It is a blow to the ego to have mistakes pointed out and to have seemingly clever solutions rejected. Without pressure to tilt the playing field, excellence will be outnumbered and attacked by the lazy, egotistical, and jealous.

Without pressure, the cream does not rise to the top.

Power without responsibility causes corruption because without responsibility there is no pressure.

Sure, there must be time to relax and recharge. But don’t coast.

Why iPhone?

I’ve joined the in-crowd in one aspect last week – I got an iPhone. I’m enjoying it immensely.

However, most of the things I’m doing on it – surfing the web while waiting for the kids to brush their teeth, listening to music, replaying Go games – I could have done on my 5-year old Dell Axim PDA. If I’m enjoying the new iPhone, why was the Axim sitting aside for most of the past couple of years?

  1. While I liked the Axim, I just forgot about it in all my busyness. Once it got set aside, it stayed aside. The iPhone is also a phone which I tend to carry around.
  2. Technology has improved over the past 5 years so the iPhone can hold more and process faster.
  3. The iPhone does have few killer features that the Axim did not – GPS, cellular data downloads, and motion detection.
  4. There are lots of free or cheap apps that are of some additional benefit.
  5. The iPhone does have a better user experience. The Axim ran Windows Mobile and used a stylus which was fine. But the iPhone is distinct.

Apple famously failed with the Newton a decade ago, it just seems now is when all the pieces were finally ready. Items 1-3 are just improvements in technology that are available to all competitors.

Item 4 can probably be credited to the App Store innovation. There were lots of apps for the Windows Mobile – after all each new environment is a new land grab for developers – but there was not a central place to find them. And each developer had to setup a credit card payment system so the prices were higher.

Item 5 was probably Apple’s main contribution and may be the advantage of controlling the complete vertical. The Axim was built by Dell running an OS from Microsoft. Neither one owned the user experience so could not aim to maximize it.

Item 5 also speaks to the importance of design generally in software design. Windows Mobile was functional and usable, but it did not have ‘cool’. My Sony Reader is functional and usable – by an engineer. When a friend asked about a e-reader for his mom, I had to recommend the Kindle because it is so much easier to download books.

When creating software, it is so easy to concentrate on maximizing the features and stuffing as much as possible on each and every screen. However, the most successful software will concentrate on letting the user easily do what they want to do most of the time. It took digging through 3 menues to connect the Axim to my home WAN. The iPhone asked to connect when I first tried to go online at home. If my Axim was easier to use, maybe I would have been raving about it 5 years ago. 

Unfortunately, when you are knee deep in the weeds discussing features you are in the worst place to design the user exerience. It takes fresh eyes and a bit of idiot-user to see the rough edges. The iPhone shows why the effort is worthwhile.


Have you ever talked to someone where they look at you intently while you are talking, nodding occansionally, maybe even grunting a bit? You thought they were listening but later they act in direct opposite of what you were talking about.

Were they listening but not telling you they disagreed? Were they even listening?

What is the difference between listening and simply not interrupting?

I have to say, I was impressed with the looking at me intently while I talked. I thought this person was really interested in what I was saying. But like any fake – it only fools for short while.

How to Disagree

As I pointed out in my earlier post, often people get stuck on arguing whose solution is better. It does not really go anywhere because

  • they are really solving two different problems, and
  • they are not even listening to each other – just listing the benefits of their own clever solution

 The way around this standoff is to

  1. Tell the other person the benefits of their solution. This will shut them up because they see that you finally understood what they have been trying to tell you.
  2. Then tell them the problem with their solution.

Notice that nowhere does it say to describe how your solution is way better. No need to even mention your solution. Just list the problems with the other solution. Either the other person will deny that those are indeed problems, in which case you can address the real issue – that you disagree on what the problem is – or they will agree that their solution is imperfect which should lead naturally to a discussion whether there is a perfect or more better solution.

By just insisting that your solution is better (and thus you are smarter) will get you nowhere. But by continuing to list problems, the other person is challenged to solve them and will then discover your solution (or perhaps a better one) themselves.

And then you agree 🙂