Archive for the ‘Software Development’ Category

Awesome Support from The Next Generation!

Saturday, June 2nd, 2007

Darrin Lythgoes goes the extra mile! As a new customer of his genealogy software, The Next Generation (TNG), I ran into a little bit of trouble importing images. The export file from The Family Tree Maker contains no image information (why ?), so I was faced with importing literally hundreds of images and relinking them to people. Darrin cooked up a quick script to import the images which will make the task of relinking much easier. I love great customer support and Darrin delivers! Thanks a ton Darrin!

Addition and Subtraction with Two Fingers

Wednesday, April 25th, 2007

I noticed my second grader was counting on his fingers to solve simple arithmetic. Somehow memorizing the answer to 17-9 wasn’t worth it. He was perfectly happy employing 8 fingers in pursuit of a solution. Now most kids can add and subtract easy numbers ending in zero or five. So it occurred to me that if you are going to count on your fingers, you only need two fingers at most to change the problem into something easier. For example,


Can be transformed to an easy problem by adding one to both the minuend and subtrahend



Playing with Ruby on Rails

Friday, August 11th, 2006


I’ve started playing with Ruby on Rails. For simple CRUD interfaces, I’ve found it is very fast and easy. Here is a demo of multiple related selection boxes using Ajax. In the screen shot, Zip Code has been constrained by the previous selections for State, County, and Post Office. It works like you would expect, selecting a State constrains selections for County, Post Office, Zip Code, and selecting a County constrains Post Office, etc. I used Richard White’s excellent Ajax Scaffold for this demo. The data is from the 2000 Census.


More on Commoditization

Tuesday, April 11th, 2006

DSCN5295, originally uploaded by trekr.

I should have said more in my last post about how a skill may become a commodity.

Standards, tools, and for that matter, any advance in the art that constrains the allowable solutions such that the output of different practitioners is undifferentiated, leads to commoditization. For example, a hand saw requires more skill to use than a circular saw. However, anyone with reasonable competence can cut wood more than good enough with a circular saw. For most cuts it doesn’t matter that the handsaw is more precise in the hands of an expert.

There are many great photographers now that we have digital cameras. The technical aspects of film type, shutter speed, focus, lighting, are hidden from the user. However likely it is that a skilled photographer can do more with film, even the pros have switched to digital cameras for most of their photography.

Java programmers don’t need to master memory management or even know what a pointer is. Fundamental algorithms are now in libraries. Most programmers will never need to implement a sorting routine. Does Java constrain the expressiveness of the programmer? Certainly, but not in ways their customers care about.

In some sense all tools abstract and hide details. That is the power of the tool. One need not master the details to successfully use the tool to solve a problem. In order to hide, you must constrain yourself to a hiding place. If your hiding place is big enough, it’s good enough.

The process of commoditization is a net benefit for most of us. It is difficult when your skill becomes a commodity and you need to make a transition. Hopefully, these incomplete thoughts will give you some insight into how to see when its about to happen to you.

Never do the Last Thing

Wednesday, June 1st, 2005

Today I heard it again.  "Our software team is very passionate, and we work seventy hours a week".  Well, I don’t believe it.  Besides, its not a good idea to try to consistently work seventy hours a week. 

I once read a story about a woodcarver that decided to work late to finish carving a detail in the face of a statue he had been working on for months.  Even though he had worked a full day and was tired, he wanted to finish just this one last thing before he left for the day.   His chisel was dull and wasn’t cutting well, so he pushed a little harder and suddenly cut out a large gouge that ruined the entire piece.  After that experience, he vowed never to do the last thing.   (If you know the origin of this story please help me with the attribution).

Knowing the story didn’t stop me from doing the last thing until one day after adding some functionality, I broke the entire software build.   I called my wife around 4 p.m. and told her I’d be an hour late.   Then I loaded up the debugger and started stepping through the code.   It seemed like in just a few minutes she was calling me back asking where I was.  I looked at my watch, it was 8 p.m.  That was literally, the 13th hour.   I was tired and making mistakes.  So I went home, and the next morning, I solved the problem in the first 20 minutes I was at work.   The power of the subconscious I suppose.  After that, I vowed, "Never do the last thing".

If you are a manager, ask yourself, do you really want someone carving on the face at the end of the day ?   Yet in the software business there is almost a cult-like ethos of the endless string of all nighters.   I suppose this isn’t limited only to the software industry, but that’s why we are afraid of the hospital.

I’m not impressed when creative people claim they work seventy hours a week, consistently.   For that to be true, you have to count a lot of non-productive time like reading emails, lunches and dinners, overnight travel, commuting, meetings you don’t need to be in, smoke and joke at the water cooler, browsing, blogging, etc.   We’d all be better off if we were more honest about what work is and how many hours we really "work", because then we’d have more realistic expectations of the people we lead.   I estimate that in a solid eight hour workday,  if you can average five hours of quality work, you’re doing well.  In fact, it is a significant challenge for managers to create a work environment that allows engineers to have those five hours free of meetings and other interruptions.

In the mid nineties I worked for a company that implemented policies that did allow at least five solid hours a day.  The first policy change was the concept of a time bank.  No sick days, or vacation.  If you didn’t log 40 hours at work, the difference came out of your time bank.   The policy was based on two observations backed by data.   A large number of exempt employees were not even physically present 40 hours a week, and a small minority was working excessive hours and had a higher voluntary attrition rate.  In addition, our customer had begun to adjust proposals for future work based on historical actuals.   So "free" overtime wasn’t free anymore, it was a handicap.  At the same time, the company instituted the concept of core hours, from 9 a.m. to 3 p.m., and required that you notify your supervisor if you weren’t going to be available during core hours.   Meetings were also limited to core hours only and required 24 hour notice if it wasn’t a standing meeting.  Finally, managers were held accountable for earned value relative to the hours expended.  Productivity actually increased with these policy changes.   Its easy to understand why.  There were less meetings, but everyone was there and on time.  There were less mistakes, because people weren’t tired.   Our ability to stay on schedule improved because we were measuring.  Everyone was happier.

I believe when we create a culture that pressures people to pretend that they work the mythical seventy hours a week, we actually get much less.   Why is it that people that claim they work seventy hours a week never finish anything early ?   Its simple, they didn’t plan to finish early.  And that’s the crux of the whole matter.   Teams that fall into this trap of kidding themselves that everyone is working a seventy hour week are poorly managed.   That’s my genuine verdict.