An Example of Why You Should Hire A Software Development Consultant

An Example of Why You Should Hire A Software Development Consultant

Yesterday, I had a phone consultation with a potential client. I was recommended to them by a former coworker to help solve an integration problem. They have an internal development staff who are all very talented. Their knowledge and experience is very deep in the areas they deal with day in and day out. But in this area of distributed and stateless workflows across systems, they are struggling. I am a software development consultant specializing in system integration.

It’s not that their internal team can’t solve this problem … given time. The issue is the expense of them solving this internally could be very big.

First, there is the cost of the time the team spends on researching their options and working through the issues one by one. There is also the lost opportunity cost of not delivering other enhancements and upgrades their customers need and want.

Then there is the very real potential cost of getting something wrong. What if they introduce a security hole? What if they choose technology with a known exploit?

At this point I don’t know if they will hire me or someone like me to help them with this. Just based on some of the comments by the development lead on the call I suspect they probably won’t.

It’s not a new story. Internal development teams are expensive and the costs related to them are often under the management microscope. Over the last couple of decades the mantra of “do more with less” has been the justification for pressing development deliveries and timelines. This increases pressure on development managers, directors and VPs to not want to disappoint the C-level players.

In other words, internal development teams are often under pressure to say “yes” to just about any request. Yes, I know companies have policies and procedures in place to prevent it. Yes, I know companies claim to empower the development teams to make the right decisions, not just the popular ones. But I can point to a very long list of people who were pushed out or fired outright for correctly pushing back on unreasonable requests, deliverables and timelines.

Also … and I hope I’m not telling you anything you don’t already know … we developers have egos. Some are bigger than others, some are easier to bruise than others but all developers have egos and the prospect of admitting they don’t know or understand something can be too difficult to face. Especially when they know their next job review is just around the corner. Humans always act in their own self interest.

But bringing in the right outside resource at the right time can not only help the team break through an obstacle it can help prevent future obstacles from being anything other than a small bump in the road.

Think of it this way. Many companies have in-house lawyers to handle the day to day legal issues every company faces. But they also have outside counsel available, often on retainer, to handle specialized areas as needed. Development teams should be no different.

I spend a lot of time dealing with workflow integration issues between complex systems. I am very good at solving those problems. It is likely I have seen the exact or very similar integration scenario any team faces today. Some are simple to solve; some only look simple until you dig into them; and some should be avoided at all cost.

Today, building web and mobile data entry forms and display screens and such are formulaic. There is literally a cookbook process to creating intuitive user interfaces designers can easily make look great. But there is no cookbook for handling workflow integration between systems because they are situation specific. There are best practices for API layers but having spent years in the trenches I can tell you those best practices are ignored almost as often as they are followed and they are constantly changing. The “right” way to do it now, isn’t the same as it was a year ago and it will change again in the next year.

Relying solely on internal resources for unique problems like these isn’t always the best option. An outside resource can help you quickly eliminate the chaff and focus on the right options to solve the problem and break through the roadblock. If custom software is needed as it often is, the outside resource probably already has the right patterns to use and can help the team easily integrate them into the existing software.

Yes, you will pay the outsider a much higher hourly rate than your internal resources. But, if your internal resources had similar experience and resources, they probably wouldn’t be working there.

Leave a Reply

Close Menu