BKeeney Briefs

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?

Our deck was original to the house and we’ve given it some TLC since we moved in.  This summer, however, the stairs started to rot and finally one gave way.  We contacted the contractor that had done some of the previous repairs on the deck for a quote to replace them.  How little did we know that the contractor had gone off the deep end and was setting everyone up for bad feelings and way too much stress.

When Total Bid does not mean Total Bid
The contractor came to the house the same day I called, and then gave us a bid in writing the next day.  I’ll skip the details, but here are the lines in question:

Total Bid:                        $x
To be paid at signing of contract:    $y
To be paid after completion of work:    $z = x-y

Total bid of $x, right?  Seems simple enough.  We added a power wash and some staining into the contract and that pushed the total up to $x + $600.  Well, we really screwed up and we wrote a check out for $x which the contractor promptly cashed the same day (Friday).

By Monday, we had a pile of stained lumber in our garage and the contractor was asking for another $500 to “make payroll”.  We promptly told him no, we’ve already paid more than we should have.  And that’s where it stood for a week as the contractor refused to return phone calls and emails.

When he finally met, he informed us that the total was $x + y + z and that we were trying to screw him out of the money he’d already put into the job.  So in his reality Total Bid was, at best, misleading and at worst, fraudulent (in my opinion).  I asked if he was willing to go to arbitration for the amount and he refused.  He was offended that we thought he was a liar and left in a huff.

Keep in mind, we’ve written software that does invoices and have been dealing with multi-million dollar projects for a large chuck of our careers!  I can’t imagine ever writing an invoice that was so bad that it confuses the client.

The Saga Continues
After thinking about it, we said the original bid was a little light so agreed to pay more.  He said great, but his ‘lawyer’ told him not to do any work without payment in-full for fear of us canceling a check before it was paid.  Never threaten geeks because we asked for the lawyers phone number and promptly did the reverse look-up to find out that the lawyer is a bankruptcy lawyer.

We paid the amount in full and he refuses to do the work until the check clears.  I have some serious doubts as to if he ever shows up again….

I’ve checked with the local Better Business Bureau (BBB).  He’s had 3 complaints in the past 24 months.  None of which were resolved.

The Lessons For Me as the Consumer
•    Check the BBB before deciding on a contractor.  It used to be you had to call their office and now it’s all online.  It’s not very hard to do and you should just do it.
•    Get multiple bids regardless of past experience with the contractor.  With a second or third bid I could have called his bluff when he said it was more money, or it could have proved to me, upfront, that his bid was too low and I would have flagged it

The Lessons for Me as a Contractor
Wow, where do I begin on this one.  My contracts are already much better than this guy’s half-pager.  Of course, in reality we’re talking about much bigger sums of money and longer periods of time, but that really doesn’t mean a thing.  A contract is the first place your customer is going to turn to in case of a dispute.  Other lessons:
•    Clearly define what work is to be done in as much detail as possible
•    List any assumptions and limitations before starting the work
•    Clearly define what the payment schedule is
•    Define how disputes are to be handled
•    Be as professional as possible and don’t let emotions get the best of me
•    Have a standard contract format you can use for everything
•    Oh, and don’t use “TOTAL BID” for anything other than the total. 

I’m sure there are more lessons to be found in this story and I’ll be curious to hear your reaction to it as well.  As a contractor thankfully I have very few horror stories with clients having issues with work.  The one case that I can think of, the client has unrealistic expectations of what we (as software contractors) would do for them.  They expected us to do their end-user tech support since they had no one in-house to do it!

Their requirements document was a mere two paragraphs long with most of it being bullet points.  In their emails that kept using the term ‘easy’ when describing the project.  Needless to say, those two items are now ‘red flag’ items.

It’s been quite a project.  I was first brought in to write reports using Crystal Reports and do miscellaneous things in their VB6 project.  Back then, we were still waiting on a lot of the things to get coded so they had me work on preferences.  Then user security.  Then MapPoint integration.  Then flat file imports.  Then payroll.  Wait.  Did I say payroll?  Did I know anything about payroll?  Nope.  Not a thing.  I now know way more than I’d like to about payroll in the United States.

I finished coding payroll and we were STILL waiting on our resident ‘genius’ (an MBA with Microsoft certifications up the ying yang) who still didn’t have the general journal done after months worth of promising it was ‘just about done.’  I was tasked with getting budgets up and running and account balances were taking forever (15+ minutes to get 300 account balances).  Because our self imposed release was quickly approaching we couldn’t wait anymore so I created the General Journal tables and code to deal with populating it based on all our various accounting transactions.  Now, 300 account balances take just a fraction of a second (as it should).

We released it to the public and we won some awards.  And then we discovered why using Microsoft Access/Jet as an accounting database was a horrible idea.  Database corruptions were commonplace because client networks were so bad that Jet couldn’t fix itself.  We start stashing copies of the database ‘just because’ and gave warnings that users should compact and repair their database on a regular basis.  It was at that point the owner allowed me to look into using SQL Server instead of Access.  Did I know anything about SQL Server and VB6?  Barely.

Going from almost zero knowledge, we got SQL Server up and running in about six months (while still releasing new features).  Since we had long since figured out how to minimize corrupted databases (but never completely eliminated the problem) the client naturally decided that SQL Server wasn’t important to his long term growth.  So SQL Server was (mostly) abandoned.

Along the way we refactored payroll to speed it up by a factor of 10.  We rewrote sales tax to accommodate the crazy schemes the politicians come up with to get money.  We were able to convert QuickBooks into our package with roughly 99% historical accuracy.  We investigated many things to see how long and how hard it would be to implement such as report designers and integrated charting and even releasing to foreign countries.  We rewrote large sections of code and changed out controls in Visual Basic that were better than the existing controls.

I mentioned that we mostly abandoned SQL Server.  That’s not really true.  The one full-time developer on their staff and I kept developing as if we were using Access and SQL Server which was a great idea because eventually they sold copies of the product to some very big companies.  And naturally Access/Jet choked and died a miserable death in those high data environments.  Our forethought saved our collective bacon when we were able to switch them over to SQL Server with minimal effort.  Jet errors vanished nearly overnight.

As a company, my client won some local awards as a great place to work in the Kansas City metro area.  They treated me as an employee (for better and worse) which meant that I was invited to their Christmas parties and got dragged into profit sharing meetings.  I knew the employees as well as I’ve known anyone I’ve ever worked with.

But as with all projects, this one is now mature and stable.  Sure, we have a huge laundry list of things we’d like to change, but we’re no longer in that startup mode where every day is about coding something new or where every day is an emergency because we (or a customer) found an issue that has to be changed RIGHT NOW.  I feel as if the really exciting part of the project is over.

So when an opportunity came along to work on an even bigger project for a very large company I couldn’t pass it down.  So starting Monday, I start working on a big project for a Fortune 100 using agile development methodology.  It’s a big deal and it has some risk but the potential rewards are huge.  I get to learn about being part of ‘scrum’ and to be part of a team where we have code reviews and formalized coding standards.  These are, frankly, something I’ve wanted to implement for a long time.

Doing a quick check on Friday revealed that the accounting project has around 975,000 lines of code in 700 project items with 200 reports.  How many of those reports did I create?  Maybe 10.  How’s that as a switch-a-roo from when I started?  As I left the building on Friday I told the client (really my friend at this point) that I appreciated him letting me play in his sandbox for five and half years and that it’s not really goodbye.  I’m sure there’s some more things to build and another couple hundred thousand lines of code to write.

The March/April 2008 edition of REALbasic Developer is out. The topic of my BKeeney Briefs column was Differentiation Yourself from all the other developers that are bidding on the same job.

What are your thoughts on the topic?

Having your own business isn’t easy.  In fact, it’s the hardest thing anyone could ever attempt because the work never ends.  If you’re not doing ‘real’ work, you’re thinking about it.  How do you find the next bit of work?  What’s my next article going to be?  What product should I work on?  The questions are endless.

Our industry, in particular, isn’t known for it’s healthy habits.  We spend way too many hours in front of computer monitor.  My wife half-joked at last years Real World conference that you could tell who the programmers were because they were all pasty-white.  And that’s not a slam on anyone because she’s a programmer too and has been for longer than me.

Last Fall I was working a lot of hours.  I was tired all the time and I just felt miserable.  I was turning down work which is always a bad sign.  I knew I had to do something.

The first thing I did was hire an employee.  Some of you probably feel that’s a bad idea but I found an awesome developer.  In fact, he’s better at a lot of stuff than I am which is great because as a company I can now pursue projects that he wants to do as well as those that I have a passion for.  It also means we (collectively) can help out on some open source REALbasic projects.  So now, two of us can do more than just one of me was doing.  That was my first step.

For my second step I started going to the gym again.  I’m no longer funding a service I don’t use.  I go every other day and do a combination of weights and aerobic activity.  I’ve lost 15 pounds and I have more energy than I’ve had in a while.  Perhaps the best part of the gym is that I go to the office and do better code in less time.  My thoughts are focused and I’m generally sure about what I’m doing.

For many years I studied Aikido (earned a brown belt) and one of the many things I learned in its teachings is that Mind and Body are one.  Where the mind goes the body will follow and the reverse is true.  Where the body goes the mind will follow.  So if you don’t exercise your body you don’t exercise your mind.  I loved Aikido until my knees gave out but the truth still holds – you need to exercise your whole body.

Whatever it is that you enjoy that is not centered around the computer – do it!  If that means pounding nails while helping build a house, do it!  I know several developers/business owners that do that for fun.  Join a gym.  Join a league.  Go take a yoga or Thai Chi class.  Take an adult education class at the local community college.

Just do something different.   Something that’s NOT computer related.  Give your mind something else to ponder about for a while.  You’ll be amazed at how much better  you feel and how much better your code is.

So what do you do to refresh yourself?

I ran across this blog today titled Wide vs Deep and it got me thinking (which is always a scary thought). The blog is about how programmers are promoted to managers even though the thought processes are different. Managers are wide and shallow and programmers are deep and narrow.

While the article specifically references programmers that get promoted to managers I think it’s appropriate to talk about it since many of us are small business owners.  That means that we don’t have managers and programmers.  Forgive my poor English when I say, “We is it.”  So how do those of us that do both deal with being the programmer and the manager?

I’ll start off with a little bit of my background since I think it explains a lot about me and how I think about things.  I grew up in farm country in rural Illinois.  My role models growing up were men that with bailing wire, chewing gum and a welder could fix any piece of machinery under the sun.  None of them were specialists in anything and had a very wide grasp of reality.  They were tenacious and didn’t give up.  I think that’s the nature of being a farmer.

I attended an engineering college on the south side of Chicago just blocks away from Comiskey Park (and the Robert Taylor homes but that’s a different story!) where I earned a degree in electrical engineering.  Going to a private school was a struggle financially so I co-oped, did internships and worked my way through school in six years.  My education ran very deep and narrow in areas related to electrical engineering although you can argue that electrical engineering touches many areas of engineering (thank you very much for that lovely class called thermodynamics, by the way).

By the time I had graduated I had two full years of experience as an engineer and landed a great job solely because of my experience.  In my new job working in an industrial environment (steel mills and foundries) there was “the problem.”  The problem might be simple or complex, but it was my job to figure it out.  One day it might be fixing a glitch in a PLC program, looking at the circuitry of a steel hardness testing station, programming a new labor saving device or doing the load calculations for a new transformer.  The solutions involved researching the issue, evaluating the solutions, engineering the solution, getting the approvals to do it, and then do it!  I would call that the funnel approach since it starts wide and narrows down considerably towards the end.

As a software developer and the owner of a business with programmer employees I find myself being torn between being wide and deep.  I can’t do both at the same time and I can’t switch between the two quickly or easily.  When I’m in management mode I just can’t go deep without a transition period.  Thankfully, going from programmer to manager is an easier process even though it’s frustrating not being able to finish what I was working on.

From a project management standpoint I don’t need to know the details of the class/module that is being used or modified – I just care that there’s a solution.  But the programmer is concerned with the implementation details of that class/module.  They couldn’t care less (most of the time) if the customer is 30 days past due on an invoice or what the next project is.  They’re too deep into the details to care and, besides, that’s a “management problem”.

If you’re the sole developer in your business, it’s all too easy to miss the details or go too deep into the details too soon.  If you’ve ever been thinking about the code at the bidding stage and you’re designing classes or thinking about the details of how you’ll implement the project then you’re probably too into the details too soon.

Likewise, when you’re creating your bid, you can’t just guess at how long or much money a project should be.  You need to determine some of the details and maybe do some proof-of-concept programming before creating the bid.

So it’s not just as simple as being wide or deep.  You have to manage the process – especially if you’re on your own.  Here are some recommendations you can try.

1    When you first start looking at a project don’t go too deep at first.  Write down all of the major areas you (as the programmer) will need to take care of without getting into implementation details.
2    Identify those areas that you need to research and do some proof-of-concept programming.
3    Do your research and proof of concept programming but do NOT polish it.  Do not spend a lot of time on it, but also code like you’re coming back to it later (which hopefully you will if you’re awarded the bid).
4    Stop and re-evaluate your original major areas and assign values to them and finish your bid.

Once you have been awarded the work, you can use the research and proof-of-concept coding as a starting point.  You can start going deep into the details and code but keep in mind that the management of the project is not over yet.

As you gain experience it becomes easier to estimate.  You just ‘know’ that it takes a certain amount of time to do some task.  You’ve done it before and you know the pitfalls and complications that can arise.  (Shameless plug coming)  Use a product such as Task Timer to track your time.  If you don’t know how much time you spent on projects in the past how can you accurately estimate similar projects in the future?

In a future post I’ll talk about how to climb back out of the pit of details.  So what are your thoughts?  How do you avoid going too deep too soon?

People hate you if you’re a developer and you sell software.  Yes, it’s true.  Get over it.  No matter how hard you work at creating the perfect application someone will nit-pick something.  It doesn’t matter if you spent a year in development and six months in beta testing, someone will log a bug within the first 30 minutes of release.  Okay, the time frames are exaggerated but the end result is the same.

This means that you, as a developer, have to have thick skin.  Someone will always complain about something.  It happens all the time.  If you add feature X, users will complain that they “need” feature Y.  If you fix a bug and cause another one users will complain that your software is buggy and unstable.

If you panic every time you get a negative email then you’re probably in the wrong business.  Email is notorious for giving the wrong impression because you can’t tell if someone is joking or not.  Add the fact that writing is an art form that most people haven’t mastered and you’ll often misinterpret their intent.

Don’t even think about reading a review of your software by yourself.  Very few reviewers will give your software a perfect rating.  If they did, they wouldn’t be doing their job.  They get paid to point out a flaw, missing feature or bug in your software.  Have a friend or a spouse read the review first to get a relatively unbiased opinion of the review.  Then honestly look at the review and work on improving your software.  It’s an opportunity to improve.

Websites like VersionTracker allow feedback from users on software they’ve downloaded.  Be very careful when reviewing the feedback from those sites as generally happy people don’t feel inclined to give feedback.  Unhappy people like to spread their misery so bugs and missing features can cause a rating to go down quickly.

On the flip side, the next time you think about sending off an email or posting onto a support forum, think about how the developers might take your post.  Is it incendiary or is it respectful?  They’re human just like you.

Greetings and salutations!  My name is Bob Keeney and I’m the Vice-President of BKeeney Software Inc.  This blog was started after RBDeveloper magazine agreed to publish a BKeeney Brief’s column on a regular basis.  This is a very cool thing and I’m happy to do it.  I’ve always enjoyed writing and did a lot of writing for various Mac user groups back in the day.  On a regular basis we’ll talk about being a developer and what it’s like to make a living as a developer.

BKeeney Software does cross-platform application and database development using a variety of languages and tools.  We mainly use REALbasic by REAL Software.  REALbasic is to cross platform programming to what Microsoft Visual Basic 6 was to Windows.  In my opinion there is no other tool that is as easy-to-use and as powerful than RB.  Many critics complain that basic isn’t a real language when in fact (in RB at least) it creates a native executable for Windows, Macintosh and Linux.  And this is done with one code base.

RB isn’t a panacea for developers.  RB does a great job of making a decent application that’s reasonably close among all the platforms.  However, that means it’s not a true Windows, Macintosh or Linux application without a little bit of elbow work for each platform.

RB isn’t without its critics.  Some of the well deserved and some of them just petty.  Just as with any development environment, it’s easy to make a bad REALbasic application.  For those code purists out there, I’ve seen exceptionally bad .NET and Cocoa applications for Windows and the Macintosh respectively.  Let’s face it, a bad app is a bad app.

The trick with any development environment is to learn the little tricks of the trade the make life easier.  When I use Visual Basic 6 we have a bunch tools and routines that we’ve found over the years that helps polish an application.  Without them the application just appears “not done”.  In the accounting app we work on, we have close to one hundred Windows API calls that help out with one thing or another.  So it is with RB as well.  We have our classes and utilities and little helper apps that help us out.

One such help application we use with REALbasic is QuickKeys.  We set it up so that QuickKeys calls an RB Script that does any number of things.  One such thing is to add basic exception handling into the current method.  With a simple press of a button we add the name of the object, the method and a call to our global error handler.  It beats the heck out of typing it all in.

So what tools and utilities do you use for REALbasic?