It’s Just a Simple Matter of Programming
The buy vs. build dilemma
How did I get into this mess?
Sometimes customers come to us when they realize they are being held hostage to internally developed software or processes that address job scheduling and managed file transfers. Over the years they see these turn into a Frankenstein of code and manual interventions. How can this happen?
Say you’re a development manager, IT operations manager, system architect, or development lead. Incoming! A requirement arrives for your new product or feature that demands workflow or task management, or some scheduling need.
You bring it up to your team. Some hotshot raises their hand.
Hey. That’s easy. It’s a simple matter of programming. Give me a few days and I’ll be done.
You give the task to her. Unbeknownst to you, on the forums she’s posted the following: (real posting – I swear)
In my new Java project, we have to develop a feature of Job scheduling.. for example i have to create a program in java to execute certain task in a specific time or after a regular intervals of time. can you please suggest me how it can be done? But first of all please explain me what is job scheduling in Java and how one can use this feature in their application.
But she pulls it off – or so it appears. She integrates some open source, writes a few classes, makes a few simplifying assumptions and voila! Problem solved. For now. Occasionally things go bump in the night, but she’s there to make it all better.
Time marches on
It’s now some time later. That hotshot – she left for bigger and better things. That system you addressed that scheduling requirement for – well it’s now mission critical. And the scheduler- well it’s going bump in the night – a lot! And now you need some new feature added to that scheduling code. You bring it up to your team – now a new team of course – everyone has gone on to bigger and better things. Some newby raises their hand. It’s a simple matter of programming. Give me a few weeks and I’ll be done.
And again – voila! Well, not so much. That bit of code is now replaced with a framework and an API and a ton of code. More time is spent documenting the API than was spent in the original development effort. And nothing in the new code is working as expected or being delivered on schedule.
Ask yourself – is your team’s time better spent adding features to the product or system that customers are paying you for, or in learning the intricacies of timer tasks and job scheduling code? Say you’re an analytics company. Your clients are paying you for insights from your data analytics. They are not paying you for your workflow or file transfers.
So the next time you get a new set of software requirements, ask yourself if these requirements are better satisfied by investing your precious resources in building new software in an area not core to your business, or whether purchasing a supported toolset with dedicated knowledge and expertise is a better choice. Just because someone on your team thinks it’s just a simple matter of programming, ask yourself. Really?