The Quest for perfect IT solutions: A Tale of Two Cities

Dickens wrote “It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness….”  Too often this is how I see IT solution requests; a conflict of two opposites occurring at the same time.  As we struggle to meet the demands of both internal and external customers we have to make choices: simple and easy or the maximum number of features and options, constant innovation or stability, and many more.  Sure, in a perfect world we could have our cake and eat it too, but the realities of software development suggest we simply need to balance some of these conflicting customer demands.

The promise of agile development gives us hope for faster innovation and quick turn around on enhancements and new features.  But even if we could deliver 100% bug free releases every week, would you be able to deploy them every week?  Would you want to?  Containers provide a newer method to develop, test and deploy solutions more rapidly with less risk.  And Software as a Service (SaaS) offers us additional hope here as we don’t need to do that deployment every week, so maybe we could have our cake and eat it too.

However, the software deployment lifecycle isn’t the end of the balancing act.  We must also consider how much functionality to build into our solutions.  The more complexity we build in, the harder it is to keep bug free.  But since we determined above that we can potentially solve this problem, we can try to ignore this first part.  On the other hand is “the user”.  While users beg and plead for more functionality, they don’t want to be challenged when attempting to use it.  At a cost, we can develop nearly any feature or provide many options to achieve the same result.  And while we may craft each of these to be very easy, with every option there is some increment of additional adoption complexity.  To make it easy for users we could provide “the master switch” where we pick “give me simple” or “give me expert”.  However, this just masks the problem.  The IT group still needs to support both options and most users want to be “the expert” even when they are not, thus driving more helpdesk calls.    

 

The challenge for software designers continues in our climate where we are surrounded with security concerns.  While it is easy to say all software needs to be written to be secure, we also want to say our software solutions should empower, not restrict, our employees.  Users demand they have access to the data they need even when it isn’t clear why.  Can we instantaneously grant access to a user when it appears there isn’t a reason or president for them to access this data?  In such a case, it is hard for a human to determine if this request is from a bad actor or the next employee of the month.  Our challenge is to create software solutions smart enough and dynamic enough to do this. 

 

So what do we want?  Agile development, containers and SaaS give us the promise of the best of times.  The reality of bugs we cannot always catch with testing and quality assurance combined with users who don’t always grasp our features as we designed, keep is firmly in the worst of times.  For me, it continues to be a challenge which continually forces us (vendors and consumers alike) to be better.  To continue to evolve. To the next generation of solutions and then on to the next again.  While we may never be perfect, we must strive to get there even when the demands are diametrically opposed.

At Quest, we are on a quest to make your information technology work harder for you.  This community helps Quest drive our solutions to help you spend less time of IT administration and more time on business innovation.  I encourage you to utilize this community to let your voice be heard and guide your company to the best of times.

If you feel I have missed something, want to pile on or prefer a different angle on this topic, please join the discussion by leaving a comment and following other Quest articles on thought leadership.

Anonymous