Gold-Plated Projects

This morning, I found a great post by Val the C# Gal on the practice of “gold plating” your projects.

For those unfamiliar with the term, gold-plating refers to overbuilding a project in order to make more money from it.  Val’s post raises a good questions:  how much planning is too much?  But gold-plating can extend way beyond planning.  You can gold-plate your testing, running the app through situations that will never exist according to the business case.  You can definitely gold-plate your architecture, as Val points out.  Really, it’s possible to over-do pretty much any aspect of a project.

So how do you know when you’re doing enough, but not doing too much?  The answer is going to be different for every project.  To quote Richard Caetano, software development is an exercise in compromise management.  Each project is going to have a unique set of forces affecting it.  On some projects, it just might pay off to spend a lot of time building an architecture.  On others, it might pay to spend an inordinate amount of time in QA.  There’s no way to predict what your level of effort ought to be, and how to distribute that level of effort amongst the features, until after you have the requirements. And even worse, a lot of the project-to-project decisions need to be informed by the needs of the client, and clients often don’t really know what they need.

Most businesses do not run on any kind of a plan; they can’t tell you if it is within the realm of the reasonable that they might want to start capturing a new type of information within the next x months, or if they might need to stop capturing a certain piece of data within y years.  And that is a tough spot to be in – over-build, and the client complains about the cost.  Under-build, and the client will complain that you didn’t provide enough flexibility.  The key is to put in sufficient effort during the requirements-gathering phase to be able to make an informed decisions, hopefully helping the client clarify his or her own needs in the process.

Val raises a tough questions that shows she’s truly thinking about the craft, which is good.  But the sad thing is that her question is one of the many questions that can only be answered with: “it depends.”

Rethinking Everything (or, Did I Just Have a Heart Attack?)

A couple of weeks ago, I thought I was having a heart attack.  I had all the symptoms, with the additional bonus of watching my extremities swell up until there was so much pressure, some blood vessels broke in my ankle, leaving a bruise.  It was a thoroughly frightening experience.  I felt terrible afterward, too – drained and weak for days.  My doctor assured me that I had not had a heart attack, and had a whole battery of tests done to try to account for this curious combination of symptoms.

So imagine my surprise when the EKG and all the blood work checked out OK.  Heart rhythm – normal.  Blood pressure – normal.  Kidneys – normal.  Thyroid – normal.  Some other test that I cannot pronounce – normal.  Normal, normal, normal.  Yet there I was, with swollen limbs and pain in my chest.  Whiskey Tango Foxtrot, over?

After asking me a series of questions about my lifestyle, my doctor pulled no punches.  He told me I am lucky that it wasn’t a heart attack.  He told me that despite the normal test results, I am a candidate for some sort of heart-related failure because I am at least 40 pounds too heavy, I spend too much time sitting at a desk, and that I am under way too much stress.  Apparently being plump and spending 10 – 15 hours seated every day is very bad for one’s circulation, hence the swelling.  And the chest pain?  Good old fashioned anxiety.

Some people would take this badly, interpreting it as the doctor making a negative personal judgment.  Not me.  My doctor told me exactly what a guy like me needs to hear – that the solution to the problem is in my hands.  Sure, the existence of the problem is my fault to start with; I’ve fallen prey to the entrepreneur’s inclination to focus on business to the exclusion of taking care of oneself.  At this point, however, fault is irrelevant and any time spent pondering it is a waste.  Remedy is the only relevant issue at this point, and the remedy is all me.  I must do these things:

  • Lose at least 40 pounds, which would put me at 200 pounds exactly.  I know I can do this, as I once exercised my way   from 280 pounds to 220 pounds.  If I can do it once, I can do it again.
  • Cut out excessive carbs and start including more fiber and more water.  Again, I can do this, because I’ve done it before.
  • Slash at least 10 hours per week from my work schedule immediately.  I am committed to pulling this off, although I have to admit that I don’t know how I’m going to do it.  I don’t know a single entrepreneur who manages to run a healthy business on less than 60 hours a week.  I work reasonably smart and manage my time reasonably well already – I don’t think that time management alone is going to buy me that 10 hours each week – I may simply have to settle for getting less done.  If any of you business owners out there can tell me how to work significantly less without harming revenue, I’m all ears.
  • Relax.  This one is hard for me.  It is related to the number of hours I work, sure.  But in general, I’m just not built for sitting around doing nothing.  I have a compulsion to do, and in this situation it does not serve me well.  Recreational activities actually cause me stress, because I feel as though I should be doing something economically productive instead.  I will focus significant energy on improving this, because it is important to my health.

In support of the changes I need to make in order to safeguard my health, I am re-thinking everything – everything – in my life.  I am re-thinking my business, my diet, my bedtime, my friendships, my reading material, my faith, even my consumer habits.  And as I re-think these things, I use a very simple 2-question test:

  1. Does this thing/habit/belief serve to propel me toward the best life I can have?
  2. If so, can it be improved even more?

A yes to the first question and a no to the second means the element in question gets to stay, but might be replaced by something better.  A yes to both questions means the element in question gets examined and re-tooled.  A no to the first question means the element in question is never even subjected to the second question.  Nothing is sacred right now – if it does not make me healthier in every sense of the word, it’s out.

I hesitated to share this news on my blog.  I recall making a pledge to never turn this into a “today I ate lentil soup for lunch” -style blog.  But I HAD to confide in family, close friends and select clients, because I suffered some down time as a result of exhaustion after my episode and the subsequent doctor visits that followed in the weeks after.  And when I confided in people, a curious thing happened – they let me know that I am not alone.  A number of friends and a surprising number of clients reported having experienced similar problems and receiving similar reality checks from their doctors.  It seems that we entrepreneurs tend to push too hard as a group – more small businesspeople than corporate employees had stories to share.  And similar experience or not, every single client was 100% willing to cut me the slack I needed to obey my doctor’s orders to spend a few days resting.  Mind you, a few of these people had me working on important, revenue-producing projects in which each day of schedule slip meant a loss of potential revenue.  Overall, I am very pleased with the support and encouragement I’ve gotten from everyone as I re-tool my lifestyle to ensure a longer, healthier visit than the one I was trending toward.

It is this support that made me feel comfortable sharing this news on my blog.  I figure that if there are so many similar stories within my little universe of friends, family and clients, there must be thousands of them out there in the wild, and thousands more waiting to happen.

The real kicker is that I saw this coming, although not so soon.  I had been having chest pains for months.  I had been feeling stiff and swollen after 15-hour workathons.  I just wrote it all off as “the cost of being self employed” and told myself I’d feel better if I got some extra sleep over the weekend.  I was wrong on all counts.  So to anyone with similar symptoms who might be reading this – stop.  Whatever you are doing, stop.  Schedule yourself a couple of vacation days, or take a sick day if you have to.  Spend at least 1 day resting and another in quiet contemplation of where you are, how you feel, and what’s really going on in your life.  Go talk to our doctor.  Throw up a good defense before heart problems or panic attacks hit you.  And try making some changes in your life that will help you to be healthier and calmer.

You a have a whole new life if you want to.  Keep watching this space and I’ll show you.

Discuss ‘Rethinking Everything’ here

Have I Written One of the Best Software Essays of 2004?

Over at Joel On Software, Joel is soliciting nominations for the Best Software Essays of 2004.  The chosen essays will be featured in a book.  I would love to see one of my short essays in that book.

So, in typically arrogant Hawkinsonian fashion, I nominated two pieces of my own work  ;).  They are:

Here is what I ask of you – if you believe that either (or both!) of these essays are worthy of being considered among the best software essays of 2004, go to this discussion thread and leave a comment that makes me sound like a genius.

If you think a different one of my pieces deserves to be nominated, go ahead and nominate it.  And if you don’t think any of my work is worthy, well…that’s OK too.  :p

Embracing Criticism Is Good Business

Constructive-CriticismEver since I started in this industry, I’ve noticed that software developers have a curious aversion to criticism of their work product.  On an emotional and creative level, I understand why this is so.  But on a logical, business-minded level, this kind of personalization makes no sense.

Case in point:  Much of my custom development business consists of crisis management – clients who chose poorly when selecting a developer suddenly find themselves with a failing project or a broken application on their hands, and I am frequently the guy they turn to to get things back on track.  All too often, one of the problems cited with the previous developer is a lack of responsiveness to, and acceptance of, bug reports.  One stakeholder of such a project recently complained to me that after the initial delivery, every bug report was met with a retort of “that’s not a bug, that’s a user error” from the previous developer.

Now, I have some pretty hairy user error stories.  I have seen some people do things that I will not characterize as dumb, but rather unexpected and therefore unaccounted for in the code.  But I have never seen a case where every single bug could be attributed to user error (even if I had, I’d be inclined to think that allowing a user to get themselves into that much trouble is in and of itself a bug – but that is a rant for another day).

No, that was simply a case of a developer being defensive.  The code was poor quality, and I’m sure the developer – who was somewhat inexperienced – knew it but simply didn’t know what to do about it or how to ask someone for help.  That is OK.  What is not OK is knowingly refusing to take steps to correct the issue.

What more developers need to realize is that a bug report is not a personal referendum on your worth as a human being.  In fact, I’ll go a step further and say that a bug report is not even a comment on your worth as a software developer (although a dozen bug reports against the same piece of code just might be).  Now listen carefully, ladies and gents, I’m about to get to the heart of the matter:  a bug report is an opportunity.  No more and no less.  When that user presents a bug to you, it is a plea for help, even if it is phrased in a way that sounds damning.  It is also a challenge.  And most of all, it is a business opportunity.

Call me a freak, but I get excited about bug reports.  Not little-kid-on-Christmas-morning excited, but excited.  And no, I don’t salt my code just so I can get the emotional payoff (and additional billable) of being the hero who fixes the crucial bug just in the nick of time.  I know guys who do that, and I find it despicable.  No, I get excited about bug reports for a few reasons:

  • The fix is often a chance to make something within the application faster/cleaner/easier to use, etc.
  • If the bug is due to a failure of spec, it is often a chance to learn something new about my client’s business
  • The fix is often a good excuse to either learn a new technique or apply one recently learned
  • I know that fixing the bug will make the customer happy, thereby contributing to a good relationship and continued revenue

I know that last point sounds a bit mercenary, but let’s face it – nobody gets out of bed each morning just to break even (again, this is a rant for another day).  The point is, I find all these things exciting.

Sure, once I’ve delivered something that appears to work well, it stings a little to find that there is a flaw hidden away in the product someplace.  But the sting quickly gives way to passion – passion to write software that just works, software that solves problems for people, software that people actually want to use, software that makes someone’s life better in some way, even if it is only their work life.  I appreciate bug reports because it means that the users are engaged, paying attention, and care enough about what they are doing to want their tools to work.  I usually reward a bug report with a smile and a “good find” comment rather than a long face.  Obviously, if the client is upset, I immediately switch into serious, empathetic mode, but I will never give a client negative reinforcement for reporting a bug.  I want them to feel like they can come to me when things go wrong.  I know this sounds very touchy-feely, but it really does matter to the people who depend on software apps to run their businesses or do their jobs.

The bug report is your friend, people.  The bug report is your key to a more solid work product.  The bug report is your chance to challenge yourself.  The bug report is an opportunity for you to improve your business.  Do you have what it takes to swallow your initial “I am an artiste!” reaction, investigate the bug, and deliver a fix to your overjoyed client?

If you do, congratulations!  Whatever kind of development you are doing now, you’ve got the right attitude for it.

If not, then for the love of all that is holy, do not go into business for yourself unless you can afford to hire someone to code behind you and clean up all your messes.  Trust me, your clients will not appreciate you having an aversion to bug reports.  In fact, they might even cut you loose and call me in to finish your project just so they can see the excitement in my eyes when they make a “good find!”