CONNECT

So I’m at my desk working on another “issue” with Internet Explorer. I quote it because its only an issue to someone who actually believes Internet Explorer 8 should actually be supported in 2014 and the person that drove that decision is an IT person.

I do enterprise software development. What is enterprise software development? Basically, its the anti-pattern to every single software development methodology out there. If there is an established, measured and proven way to develop a solution or solve a problem, enterprise software development does the opposite. An enterprise software project generally starts out like every other project – to solve a problem. Where people’s ability to get their work done is being impeded by a process or an application that makes it more difficult then it should be, but when the ‘enterprise’ attempts to solve it it does everything wrong. The first thing it does wrong is assemble the wrong people. Every single time. And it just goes downhill from there…

The wrong people are always chosen to “lead” the enterprise development project. This is the first place “the enterprise” goes off the rails. In the enterprise – we convene “project stakeholders”. Who are these people? Generally project managers, often who have been contracted and don’t work at the company or even in the domain of that organization, and hand picked company personnel that again are rarely an end user – usually middle managers or communications and hr personnel. These people will be responsible for ‘thinking up’ a solution. They will have little to no background in software development, but more importantly no experience in product design or delivery.

Who would this team be in the real world? Generally a product manager or designer, someone who will be responsible for making the tough calls on what the product does and doesn’t. A designer or user experience person. This person is going to be responsible for making calls on how the product is actually used, how it looks… because you know, they have experience and training in this area. In the enterprise, this is going to be one of the company personnel who couldn’t choose a nice looking font for their document – but they should have no problem designing a user interface! In the real world you’d have some developers as well. This is about the only parallel with enterprise development, because well… its development. However on the enterprise side, the development often has to be done through a remote desktop on poor hardware with restrictions, no source control and meetings. Lots of them! As many as can be scheduled!

There is another person on the enterprise development team that does more damage than anyone else. The IT person. That’s right! You will have an IT person, someone who is well versed in network connectivity, storage, and information security provide his “thought leadership” on the product. When you discuss a new feature the IT person will decide whether that’s a good idea. They object to the insecurity of the product, they won’t have any basis or merit behind their objections, they just won’t think its secure because it doesn’t have the Microsoft logo on it. They will object to the storage and bandwidth requirements for the product – again there will be absolutely no metrics to support this. They will just scare the shit out of the already inept enterprise team and then refuse to support the solution. It gets better. This is my favorite part. They will demand the new solution you are building work in Internet Explorer 8 (I’m being generous here it can be even farther back generally). Why? 99% of the time the answer is – because we have to support legacy applications. Again, what applications? They won’t have anything to support this. Is there 1? Is there 100? Who knows. The IT person is basically going to limit the innovation brought to the table in your project. They are going to waste time and money in meetings objecting to things that have a solution. Any idea what that is? Its an IT solution. That’s right. They are objecting because they don’t want to do the work. They could install another browser on the machines, they could have done that years ago, but they didn’t. So they are objecting to the effort now because as every year goes by they aren’t doing their job. They are getting used to it. You’re rocking the boat.

Try this as an enterprise software developer. Suggest a technology platform that’s 10 years old. See what happens. I’ll tell you what will happen, the IT person will object! That’s right – its too old. It will be hard to support, but it can’t be new either… because well, support. Right about now the project team is worrying about the entire solution. Its security, its resource demands and if you tried this trick – its technology stack is too old. The IT person has achieved their goal, the project will drag out allowing them to sit in on more meetings, and nothing will be done to the network. Phew.

When did the IT person get this kind of control of an organization? Why are they involved in the process at all? You know how an IT person should be involved? They should be told what to do. Here’s an idea, how about organizations solve their problems and involve the IT person only to get the resources they need. Not ask for them. Get. Them. On deployment, how about the IT person monitors the situation and uses their skills to increase access, ensure security and provide a great experience to the users. All of this is possible, its called the cloud. This is what I love most about the cloud. Want more memory? Done. Another machine? Done. Want to drop support for legacy browsers? No problem – because the only people using them are the poor souls trapped in the dark ages of a corporate IT environment. How do we know this? Well we have metrics.

We aren’t going to get the rockstar product designers or user experience gurus on our enterprise development projects anytime soon, but you know what we can do? Stop inviting IT to the meetings. When we are done we’ll tell you what we need or we’ll put it in the cloud.