There’s a fine line between catering to the needs of one’s users and/or clients and doing one’s job. Whether you’re building an application or building out a server, as a technologist it is your job, nay, your duty to tell your user/client what they need. Part of your job is solving a business problem or need, so don’t just present your user with options – present them with solutions.
When you’re creating a piece of software, it of course needs to be simple to operate, but it also needs to solve problems. When you create an application that is going to be used by someone else in an organization, it needs to meet the needs of the user and make their job easier, otherwise, what’s the point? This is an age old problem in software development – how to involve the stakeholders and end-users so you’re not just creating the application in a vacuum at the top of an ivory tower. You should be building your tools and their interfaces around the way that they will be used in production, not just around some model or abstract whiteboard drawing.
If you release an application and the users come to you saying “this doesn’t make sense” or “this is too complicated”, you should discuss this with your users and try to find a solution that will actually work for them instead of against them. However, this doesn’t mean just saying to them, “ok, tell me how to fix this particular problem for you”. You’re an intelligent, value-adding technologist! You yourself implement the IProvideBusinessValue interface! Your job isn’t just to churn out the codez that make the widgets do stuff for people. Your job is to come up with intelligent solutions that solve the underlying problem for the user and add value to the business. By just working from task-to-task to feature-to-feature, you can very easily create a piece of software that is more complicated than the original manual process it was intended to replace.
This same concept same holds true for system administrators. When someone in your organization requests a new server for some purpose, you obviously need to gather some requirements first. What kind of resource utilization are they expecting? What are their connectivity requirements? What are their physical location requirements? And so on. However, you also need to come to the table with solutions, not just a list of options.
While there are always exceptions, you should be prepared with a limited set of standard server “templates” or builds. Your standard configuration for a web server in terms of CPU, memory, disk space, RAID configuration, OS version, etc. Your standard configuration for a back-end application server. Your standard configuration for… hopefully you get the idea.
You should have a small, limited set of server configurations based on typical use cases in your organization. If a user requests a server, don’t ask them what kind of CPUs they want (or even how many), or what particular service pack of Windows Server they want – tell them what they’re going to get! Come to the table with solutions, just like a third party vendor or service provider would. And if they have special requirements, then you can discuss that with them and come up with a solution that will meet their needs, but also fit within your standards.
Just like code, server configurations – both hardware and software – should be designed with change in mind. It just takes a little inventory tracking/management and a well defined, repeatable server build process to make this happen. If you’re hand crafting solutions based on each user’s request, your inventory of possible options can quickly spiral out of control and be a nightmare to manage.
Just remember – whether you’re building software or servers – you need to listen to your users needs and be accommodating, but at the same time, don’t bog them down in details. Many times users don’t know what they really want, or they have a solution in mind for a problem that doesn’t actually exist – or they’re not thinking about the larger context of their problem. Consider your users’ requirements along with the holistic system requirements to come up with winning solutions for everyone involved. Present solutions, not options.
