Bash-Shell.Net

Lately I've found myself frustrated by some of the requests and business decisions at work. I understand where they're coming from and why they are made but I don't know how to explain that they probably aren't worth the cost to implement.

This has always been a problem for software development and IT in general. In some companies IT/dev makes all of the technical decisions and that's what the users get. My old job had a major product within the company developed this way and it ws certainly troublesome because the end users felt that it didn't do what they needed and blamed the technical teams who developed for that. The focus of the technical people is generally on a high quality, maintainable, stable, secure system that requires a minimum of upkeep. Unfortunately that's frequently in conflict with what the end users want which is, as us technical people frequently see it, to be able to do anything, any time, with no effort required. I don't mean that as a bad thing. Ideally, that's how things would be. In the real world there are tradeoffs though and you just can't have everything.

The common solution to this problem is a more customer focused IT/development department where we are selling our services to the rest of the company to develop what they want, how they want, and when they want. When there are potential issues we present them to the end user and let them decide which route they want to go. This sounds ideal. The customer gets what they want, any missing features or troublesome features are because they requested them and knew the risk. My current employer works this way. While it can work, I personally find it to be like that episode of The Simpsons where Homer finds his long lost brother who owns a major car manufacturer. Homer's brother tells the engineers to build a car exactly as Homer wants it because Homer is an average guy, so whatever he wants is sure to be something the average person will want. Homer has them put all kinds of cool things (at least to him) on the car but they don't work well together and the car is an expensive, ugly, flop that no one wants. I find software development to end up similarly. Even when you try to explain the tradeoffs and why something may be a really bad idea the end users frequently don't really understand why those things don't work together well or are bad in the long run. The understanding of why those things are troublesome comes from years of experience designing software and products and maintaining them.

The most common way of resolving issues like this which everyone can understand, technical or not, is money. How much money will this new feature/product/whatever earn the company and how much will it cost to develop and maintain. If it'll earn more than it costs, then you do it. But how do you quantify the cost of a feature that is not yet developed which requires some bad practices or ideas? Sometimes "bad" software ends up working just fine despite its issues and you just don't know for sure until you've done it. How about the cost involved in bringing a new developer (or even front line support person) up to speed on the various intricacies, one off features used by a single client, and so on? Or, as I have found to be case many times both at the new job and at my old job after we tried to involve the end users more, what if the issues like that are small individually but add up over time as more are tacked on?

I have done a little bit of initial research into how these things are done, but most of the standards so far seem geared towards technical people with a background in software development and architecture. To the marketing team or sales or financial team "We're going to have to spend more time maintaining this." and "We're going to have to rewrite this in 6 months anyway." don't really mean anything. Their completely reasonable response is "So? Isn't that your job?" But to me, no, it's not. My job is to provide you with the highest quality software possible and to continue building new software and features which do so. This means it does everything the users need (I use the word need and not want on purpose) and causes a minimal number of "Oh god, what the hell was this jackass doing?" moments when you leave the company and a new developer takes over the project because part of the value to the company is the software being reasonably maintainable and expandable after the initial developer is gone.