What is a Software Engineer — Doesn’t try to reinvent the wheel

“Hey, do you think you could add some sort of revision-history for these files?  HR is saying that the two assistants are constantly overwriting each other’s changes, because they aren’t sure if they have the latest version or not.”

“Yeah, I could probably do that.  I’d have to update the document class to link it to some sort of revision history.  I’d also have to create a new revision table, and join that to the document table. All in all, I’d say it will take me about a week.”

“Great.  Let’s do that then.”

“One question, I’m about 1/2 way through the custom workflow module for manufacturing.  I haven’t shown them anything yet.  Should I finish up with that, or should I just try to cram in this revision feature first?”

“Well, we’ve already released your document management, and manufacturing has already waited about 6 months while you worked on document management, so what’s 1 more week?  Let’s do the revision history first.  Then you can get back to the workflow feature.”

So much of developing has little to do with the code you write.  It’s not that code isn’t important, it’s just that if you focus exclusively on the code, you often miss the bigger picture.  Nowhere is this seen more, than when a developer is constantly trying to reinvent the wheel.

In the software world, the most common way to reinvent the wheel is to write software that’s been written hundreds of times before.  Usually the reason for this falls into one of 3 categories:

• The company is already paying a staff of developers, why should they pay for software they can write.
• This package isn’t 100% what the customer is asking for (might be too much, might not be enough)
• There’s not enough control over third party softare.

Take a CMS for example.  In IT departments all across the country, someone is asking for a CMS.  It’s usually someone from HR who is tired of all the forms she sends out to people all the time.  Code of conduct, direct deposit, insurance claim forms etc.  Every time someone wants a form they come to her.  Wouldn’t it be great if they could just go to a website and get the latest version?  They wouldn’t have to call her and ask if the version from April of this year was the latest.

The problem is, a lot of people think a CMS should be a simple thing to write.  How hard could it be?  A database table with a document name, author, latest date, and path to the actual file.  That could be up and running in a day or two.

Plus, if it’s written in house, the company has complete control over the entire product.  If HR wants to let people lock a file, or make it hidden, or password protected that’s all in our control.  Just ignore that this statement seems to completely contradict the previous paragraph that we can just crank this out.

Finally, if third-party CMS is used, there is no control over what language it’s written in.  What if the CMS is in php but nobody at the company knows php?

What all of these objections fail to recognize is how to best utilize your time as a software developer.

If you’re working for a software shop that creates document management systems, then by all means write a CMS.  However, if you’re at a manufacturing company your problem domain most likely isn’t document management, but rather manufacturing.  There is a large list of CMS options out there. Some are hosted, others are proprietary, and others are open source.  They’re written in Java, PHP, .NET and I’ve even seen some written in ColdFusion.

If you decide to write your own CMS, you’ll spend the next 6 months defining it, creating prototypes, creating beta, fixing bugs etc.  In the end you’ll be pretty pleased with your work, and you’ll have a nice system.  But then Cindy in HR starts using it and she realizes how much more she’d like it to do.  Now you’re faced with the dilemma of either adding those features or working on the next project.

If, however, you were to use a CMS you’d spend the next month getting it all set up and training the users on how it works.  Cindy still has a lot of ideas that she’d like to see it do.  However, some of that is simply showing her how to do it.  The features that don’t exist out of the box can be added by your developers because you have the source code.  

That frees up your developer for 5 months to tackle the project that has to be written in house.  In the end, HR is happy because they can manage their documents, and your other internal customers are happy because they didn’t have to wait 6 months for their modules to get written.

In the end, the question that should have been asked is “What’s best for my customers.”  Or, another way, “Where do I provide the most value?” In this case, what’s best for your customers is that those who want a CMS get a fully functioning one, and that your other customers get their features in a timely manner.

Additionally, you provide the most value in writing software that is not readily available outside of your organization.