Chrono-Optimism

At the XDC Keynote a few weeks ago Geoff Perlman said they’d no longer give target dates for new features.  Instead they’re going to say what’s a ‘priority’ and what’s ‘important’.  Software projects are often big and complex and it’s very hard to estimate the amount of work involved with a new feature.  “Happiness is all about having expectations met,” said Geoff and I think it’s fair to say that Xojo has typically been overly optimistic on when a feature is going to ship (much less when it’s going to be usable).  So instead they’re going to stop predicting when a feature will be released.

If you hear them say it’s ‘Important’, it’s something they’re seriously looking into.  It will be in the product in the not too distant future.  A ‘priority’ means it’s either in active development or will be shortly.  The Rapid Release Model is still in play which means we will still get releases three or four times a year.

In one sense I’m disappointed that they’re not going to give us any timeframe for new features.  I really want to know when Web 2.0 is going to ready for testing as we have a number of projects in development or about ready to start development that it would be really nice to know if it’s a 90 day, 120 day, or longer window.  Android is a nice to have feature, but since I’m not doing much mobile development it’s not that important to us, but I can see how for some it is a huge need.

In another sense I understand why they’re not going to give us target dates any more.  They’ve missed every projected release date that I can think of and I’m going back a lot of years.  It was about a year ago this week, in Berlin, that Geoff said that Android would be out by the end of 2017 when the reality is that we’ll be lucky if we see it by the end of 2018 (that’s just a guess on my part and having having been around a long time).  I would love to be wrong on that guess but it’s a new target that involves a ton of compiler, framework, and IDE work not to mention the need for Interops (a dependency) to work well.

Estimating a project is not a science.  You’re asking software developers to take a wild guess at how long a big feature is going to take.  When you make that initial guess you don’t know that replacing this small piece of code will affect this much larger piece of code over here.  Or cause this other piece to not work right thus forcing you to redo that other piece too.

In some respects creating a new project is considerably easier than replacing code.  In new projects you’re touching everything anyway but subconsciously you’re holding most, if not all, of the work in your mind and you shape it as you go.  Big, existing projects, or OPC (Other Peoples Code) projects, are considerably harder since not only do you have to read the code but also figure out the intent of the code and second guess what the original developer was attempting – not always an easy task.  I’ve never seen the code for the IDE but I’d imagine dozens of people have worked on it over the years with varying degrees of competency and coding styles.  So whatever work you do you have to read, interpret, change, and test to make sure it doesn’t break something somewhere else.  Tack on multiple environments and targets and it’s a herculean task.

I’ve spent the last four years working with my son’s FRC robotics team (team 1982) as the programming mentor.  They have six weeks to design and build a robot to a very demanding set of specifications before they crate it for competition.  These 120 pound robots are relatively complex and I’ve seen it time and time again where the kids have ‘Chrono-Optimism’ in what they believe they can get done in after-school meetings (some with mentors present and some without) and on Saturdays.  Granted, they spend a LOT of time working on the robot, but they’re just kids and most of them have never done anything like this before.  They don’t know what they don’t know and most years they’re scrambling just to get a working robot.

This year, the group of seniors really thought about what they wanted to do.  They knew it would be challenging, but they decided to change their build process and use a more modular hardware design which meant new gear boxes, wheels, framing, etc.  They also decided to build two robots which, for a team that’s never done that before, was …ambitious.  Then they decided that they wanted to go two regional tournaments.  Again, ambitious for a team that’s never done that.  From previous years they also learned something else:  they were attempting to design too much on the robot.  If there were three major tasks that a robot had to accomplish they couldn’t do all three with the resources and experience they had.  They couldn’t change the amount of time to build the robot so they changed the one thing they could – the scope of work – and made the robot simple and sturdy.

The Universe works in mysterious ways and has ways of throwing a monkey wrench into the best of plans.  The last day of build season this year happened to be a day off so the plan was to have a twelve hour work day to finish the robot and test.  Instead, Kansas City had a snow storm which cancelled all school activities.  The robot was not mechanically complete and not functional programming-wise.  The kids were devastated.  But there is a silver lining to their story.

The robot was crated away and couldn’t be worked on for weeks, but the second robot allowed them to work on the programming and driver training.  The modular design allowed them to plan the work they needed to do at the tournament before it started.  The simplicity of the robot meant that the work could actually get done in a short amount of time before taking to the field.

To conclude this story (because I’m bragging now), the team won their first tournament which qualified them for World Championships.  They were the eight seed alliance captain in their second tournament.  At the world championships, they finished 42nd of 67 teams, but were picked as part of the 6th seed alliance.  They won in the quarter finals and ended up getting to the semi-finals where they were defeated by the alliance that went on to be third in the overall tournament (out of 400 teams).  All because they examined their past behavior and decided to change it.  They knew they were bad at estimating and changed their expectations.

I will give credit to Xojo for realizing that, like most of us, they are Chrono-Optimistic in their estimates, and decided to change how they communicate to their customers.  As Geoff said, part of their job is setting expectations and they’ve been really bad at it.  It’s clear that they said ‘estimate’ and we heard it as a ‘promise’ which is partially on us.  So now we have what’s a ‘Priority’ and what’s ‘Important’.  I don’t know if this will help them, or us, in the long run but it will be different and I’m willing to play along for now.

What do you think about this change?  Negative, positive, or neutral about it?

Tools of the Trade

We are currently getting our kitchen remodeled.  We’ve used the contractor before because we know he does quality work and gets it done when he says it will be done.  Plus, when he gives us a bid, we know that he’s already calculated into the bid stuff that we don’t even know about yet.  There’s not really much difference with doing software consulting.

Most times when clients come to us they have only a vague idea of what they want and need.  Usually we can count the number of paragraphs of specifications on one hand.  So when we start our estimating process we just add stuff in ‘just because’ we know that a typical desktop or web app will require certain types of things.

For example, we know that nearly all applications are database driven.  Thus, we include ActiveRecord unless there is a good reason not to use it.  ActiveRecord gives us some other advantages like speed of development time, fewer bugs, and in an update to ARGen (coming soon) the ability to create initial List and Edit forms (for both web and desktop) with controls already laid out.  It’s far from perfect but using ActiveRecord and ARGen saves us a lot of time.

Many business applications require reporting.  BKeeney Shorts has been around a number of years and has allowed us to create code driven reports.  Now, with the integrated report designer we can give users the ability to create their own reports.  It’s still a young product, and there are things it can’t do yet, but for a vast majority of business reports it works great.  Now, instead of taking a couple of hours to code a report it now takes minutes to design the report and see it right in the designer.

We’ve used the same preference class for many years because it works natively on Mac OS X, Windows and is good enough in Linux.  We’ve developed our Window Menu class that works well too.  For web apps we have our own paging control as well as a customized sorting listbox.  These are all things that we assume we’re going to use in most projects.

Do we factor these things into our estimates?  Of course, we do. We spent time and effort to develop them in the first place.  These tools are part of our standard toolkit and using them saves us, and the client, money.  To put it in terms that our kitchen remodeler might use, he knew going in that he would use a tile saw.  He could go rent one just for our project but he’s purchased one years ago because he knows that he typically has to use one.  Renting makes no sense for him when he uses it for practically every project.

I’m not saying that you need Shorts and ARGen to get your projects out the door (not that I wouldn’t mind the sales), but if you struggle with the tedium of database programming, or you dread doing reports because the built-in tool isn’t what you need, then these tools might be good solutions for you.

Regardless, if you use our tools, or something elses, you need to establish your toolset.  Having a variety of tools to get your projects done is crucial for a consultant.  Whether you use plugins or third party code these have the possibility of saving you hundreds of hours of coding time.  At the end of the day, time equals money.

Happy coding!

Tracking Your Time in 2010

Happy New Year everyone!  This time of year is an awesome time to review the previous year and make plans for the upcoming one.

Many of us charge clients by the hour regardless if we tell them that or not.  In a fixed bid project we estimate how long it will take to do the various parts of the project and then give the client a value based on those hourly estimates.

Reliable and accurate estimates are just the first step in making your business profitable.  The final step is going back and seeing if you estimated properly.  The only way to do this is to track your time on a project by project basis.

There are variety of tools available for doing this, but Task Timer, one of our products, is a very simple and inexpensive ($24.95) way of doing this.  Task Timer is designed to be simple and easy to use.  It’s as simple as pressing a button!

Setting up Task Timer isn’t much harder.  Add your project, add the major tasks you want to track, and add your initial estimates and start using it.  The new built-in estimate graphing gives you a minute by minute graphical view into how you’re estimate is tracking in comparison to your actual time spent.

For many of our consulting clients we give them a discount rate when they pre-purchase a block of hours (usually 40 hours).  Task Timer’s new estimates feature makes tracking the hours used really easy.  When the client purchases a new block of hours simply create a new task for the project and put the block of hours into the estimate field.  Task Timer is now tracking your bulk hours used for the client!

Many people who have purchased Task Timer have told us that it pays for itself in the first week!  We can’t verify their claims but we can say that when we created Task Timer and started implementing it for all of our projects we found that our billable hours rose over 15%.  It seems we were not very accurate reporting how much we worked on any particular project at the end of the day.  If we reported (really guestimated) our hours at the end of the week the numbers were even worse!

For additional information about Task Timer, please see this link:  http://www.bkeeney.com/products/tasktimer4

Download links:

Mac OS X:  http://www.bkeeney.com/downloads/macintoshdownloads/download/36-tasktimer

Windows:  http://www.bkeeney.com/downloads/download/38-tasktimer

Tracking your time is a good reality check.  Were those products you were spending so much time on really worth it?  How much time are your blogging?  What about video production for those training videos?  For that big size month project what did you get right (and more importantly wrong) in your estimates?

Plan on getting a handle on your estimating skills in 2010.  Task Timer is just one of the tools you can use.

Estimates and ‘The Reality Factor’

Estimates aren’t very easy.  In fact, I’d say that it’s the hardest part of being a consultant because of the time and effort that goes into making a decent estimate.  It’s really just an educated guess.

Think about it for a second.  You’re being asked to figure out how much time and money it will take do something without actually doing the work.  And in most cases a client has given you a vague, rough idea of what they want.  If you’re lucky.

If you’re unlucky, the client has an OPC (Other Peoples Code) project that they’re bringing to you to fix.  What’s even worse, they give you a paragraph of what the application does, with no specifics, and expect it to be done quickly and cheaply and correctly.

The other thing that sucks about estimates is knowing that we humans are notoriously bad at determining how much time something will take.  We’re good at estimating a lot of things but time estimates are ephemeral at best.  I started my career as an electrical engineering doing project engineering work.  It only took a few small projects (and getting chewed out when my estimates were horrible) to realize that my ‘it only takes a day to do that’ estimate turned into three days (or more).

So I have my multiply by three rule.  Take your estimate, which is really the ‘if everything works perfectly the first time and I can devote 100% of my day to it’ estimate and then multiply by your reality factor.

The real trick is learning from your past successes and mistakes.  Now that I have a standard tool set of classes, controls and modules that I’ve used on a dozens of projects it’s easy to say that adding ‘X’ is 15 minutes worth of work and the reality factor is 1.5.  Creating new controls, since it has a high degree of initial failure, might have a reality factor of 2 to 3.  If you have a feeling that a client is going to be really picky, maybe that reality factor goes up a little.  If the project requirement details are scarce the factor goes up again.

Trust your gut on this one folks.  The figure at the bottom of the spreadsheet seems high sometimes.  You’ll be tempted to lower some estimates to make it more palatable to the client.  Sometimes you might have to do that to get the job, but try to resist the temptation.  As a consultant your pricing is based on what your time and experience are worth along with all the other things that go into being a business.  You have overhead, marketing, taxes, insurance, and you have a retirement plan, right?

So what’s your Reality Factor?