Monday, September 15, 2008

Philosophy of IT

Just got done having an interesting conversation with some co-workers here. The discussion boils down to this: given that you do not know the competency level of the people who will follow you in your position, is it preferable to keep the IT solutions implemented to as "vanilla" a flavor as possible, or should you take advantage of the solutions available to you if implementing them will improve the solution for the customer? The argument against boils down to the fact that if you implement a solution that the next admin is not likely to know about or have experience with, then you are being selfish because you know they won't be able to manage it or fix it if it breaks. The argument for boils down to the idea that you can't be responsible for other people's competence or lack thereof, but are hired to do your job which is to implement solutions and improve on existing ones...refusing to do this will paralyze you into doing the bare minimum and nothing more out of a nebulous fear of what might happen.

Personally, I'm for the latter argument. Any opinions out there?

}-]

6 comments:

deannie said...

Implementing a vanilla solution just because someone in the future might not understand a potentially more complex solution? I can't imagine. Isn't that what good documentation is all about? Isn't that how you prepare the path for future admins?

The business logic is clear: You have to provide value to the customer by solving problems efficiently, cost effectively and in alignment with the business goals, budgets, etc. When the business is a partner in the development of solutions, they agree to certain risks when solutions are adopted.

So the real question now is: are you partnering with the key customers in the business so that you know if your client is willing to take on the risks of the 'right solution' or wants the less risky, limited 'vanilla' solution?

Those are my two cents on this!

Walt Everly said...

Ditto what Deannie said. Implementing a solution based on the competency of a future admin indicates 2 things: 1) misplaced priorities (customer should be first) and 2) poor hiring/replacement practice; If you've raised the bar, it's definitely in the company's best interests to find a replacement with the qualifications to fill your shoes.

Andy said...

I think that both sides of the argument have merit depending on the environment you're in.

While I'm strictly opposed to complexity for the sake of complexity, intentionally neutering a solution to make it supportable isn't a good approach IMO.

However, if you operate in a high-turnover environment it can make very good business sense to keep things as simple as humanly possible for the sake of user support. Certainly having such high turnover is another business problem, but one that I think falls out of the realm of this discussion :)

LuAnne said...

Can you imagine what the world would look like if everyone followed the first line of logic - keep it simple, don't improve, because simpletons might follow? What an idiotic approach to life! Everything can and should be improved on whenever it can.

Anonymous said...

It doesn't matter how you do it. Documentation is important but if a simple person or a smart one follows and they either don't understand what you did or don't like it they will just set it up the way they want. Solomon troubled with that same question in the Bible. Who would follow him and inherit all his labor. His final resolution was that it did not matter because all human endeavor is vanity.

Travis said...

I'm going to side with the vanilla solution. keep your interests or opinions out of the customer's TCO (Total Cost of Ownership). And a document can only capture so much. Who do you count on when things can and do go wrong, the custom sexy solution with a absentee architect or the solution you can walk up to and get busy fixing or have pre-configured spares etc.

I'd also like to disagree with the assertion that this does not provide a way forward, it does, but a slow, steady, and unglamorous one.