Just Because You Can Doesn’t Mean You Should

Do you struggle with this too?

It can take different forms:

• ‘Doing it yourself’ when it would be better to let someone else handle it.
• Gold plating, which is adding more features because you think they are ‘cool’.
• Putting extra effort towards something other than your product without any potential value to the customer.

And more.. Heck, I’ve caught myself doing a few of these just recently. The other day I received an email from a new student of my online project management training. There were warning messages showing up all over the place, and she never received her login details after purchasing access to the course.

I jumped in right away and fixed it as soon as I could. It turns out my web host had upgraded their versions of PHP and mySQL, and the software I purchased to deliver the training was using some old, deprecated PHP functions.

But as I was sitting there debugging the code a question crossed my mind.

Why am I doing this?

Doing It Yourself

I resolved the issue. I can debug php code on my own server. But should I be?

Should I even be hosting this on my own server where I’m responsible for all of the configuration, design, etc?

Would this problem have happened in the first place if I didn’t insist on ‘doing it myself’ and let a team of people who are really good at avoiding problems in the first place do it?

The answer is no, it wouldn’t have happened. My students would receive a better experience and I could have spent more time developing new training material or writing to help more people, instead of debugging code.

So I’m looking into migrating my training courses to a new platform, hosted by a company who knows what they are doing.

I just freed up a few hours per week of my time to do more teaching and writing. Sweet!

Gold Plating

Sometimes as developers we think we know what the customer wants better than they do.

It’s true that sometimes they don’t know what they want until they see it. There have been several occasions in my career where I had my teams develop prototypes ‘on the down-low’ to show to a customer because we knew they’d love it when they saw it, and authorize us to proceed. And most of the time, we were right.

But gold plating occurs when you go further and fully develop new features in a product without the requisite assessment of need/value from the customer and without accounting for the additional work in your schedule and budget.

And yes, I’m guilty of this too. There are several aspects of my online training that I spent considerable time on that no one uses. If they were scaled-down features to be used for experimentation to gauge student interest that I could enhance later if the need was justified, excellent. That’s iterative development, and is wonderful. But I spent a long time on some of these features that are now happily hosting a family of pet dust bunnies.

Fluff

New project managers fall into this trap all the time with documentation. I know I did.

You spend tons of time on a project management plan because you want to make sure an auditor who might review your work would say “You get a gold star for making it look important, especially with all the flowery language and the fact that it’s 300 pages.”

Yea! You can knock someone down by throwing your plan at them.

Here are the lessons I’ve learned and want to convey to you about documentation:

1. Identify the ‘customer’ of your documentation clearly
2. Every word must add value to the people you identified in # 1
3. The shorter and more concise, the better. The people in # 1 might actually read it.

If you can play bull$#!t bingo as you read through your documentation, try again.

Better yet, put your bull$#!t detector hat on as you are writing it in the first place.

Just because you can doesn’t mean you should.

What are your examples of doing something you shouldn’t have?

Come on, it’s very therapeutic.

It’s easy, just start with something like “Hello, my name is Josh. And I’m a gold-plater.”