Heh, AadityaSood linked to a comment by Kragen Sitaker on another blog where Kragen discusses what “Enterprise Software” actually is. It is a funny characterization of how decisions are made at big companies.
There was also another comment on that post by the same Kragen Sitaker, where he lists some major players in the field of databases that *do not use so-called enterprise software*. A very interesting list with some very interesting numbers.
So, what about enterprise software?
In my own experience, the basics are correct:
1. Expensive, slow
2. Weird decision-making process
3. Importance on guarantees, delivery dates, service-level agreements
4. Little attention given to the technical aspects
I’m not sure this can be avoided in a typical scenario, however:
1. Clients usually don’t know what they want. They need help.
2. The people they ask for advice are usually the ones who want to sell the product.
3. So the advisors are interested in creating new wants on the client side.
4. Furthermore, the consultants are not interested in pressing the client to hard for fear of loosing business.
5. Sometimes the time saved using the software does in fact make up for the costs incurred, even if the process of getting there was terrible. There is little comparison.
Basically, I think the main difference is this:
1. Money represents existing power structures in the process that lead to warped decisions.
2. The real gauge for software quality has no place in the process. In fact, the factors are hardly known at all.
What are the factors? From what I can tell from my own experience:
1. Fun
2. Elegance
That’s it. Human qualities will let you recognize quality software even if you cannot describe it. It was fun to make, you enjoyed testing it, it is elegant, you love it.
So why won’t developers in an enterprise-setting balance the two sides – money and quality? In an enterprise setting, the eternal triangle is this:
Functionality
/\
/ \ = Quality
/ \
Time----Money
If you’re doing business, you’re trying to sell specified functionality within a given time-frame for a given amount of money.
Compare with what I’m saying:
Time + Fun = Quality
Think about Oddmuse. I really like the code. It’s tight. It’s readable. It’s fast. It took forever. Ideas and code take *time* to grow and bloom. You can’t do it 40h a week.
Even if a project was given neither a due date nor a fixed number of hours to work on it (money), it would not be quality software. Nobody would essentially give it endless time and money in order to get perfect quality à la Schröder. Why not?
The entire thing requires *trust*. You need to trust developers to have the right sense of elegance. You can’t put it in words. You can’t verify it. I certainly would not trust my coworkers with my private projects. Much less people from elsewhere.
That’s why writing software *for yourself* works best.
I’m assuming you have the skills to do it of course. The point is that you will know yourself when the quality is just right, and you will know yourself that it is worth it to invest time and money in it.
In the future, when FreeSoftware is as important as it deserves to be, more people will realize that you cannot just “take” free software projects and use them. You have to *trust* them. That is, you can either trust other people who trust them, or you can joing them, and develop the trust you need. I think more and more developers will be hired to “keep eyes peeled” and just do whatever needs doing in free software projects, just so that their employers are up to date and know what’s going on, and have the know-how to do what they need.
What kind of trust would people have to invest in me, if they really wanted to use my software?
1. Is my sense of elegance good enough? In other words, is the code readable, is the user interface usable, is the configuration understandable, is the change management doable?
2. Do they appreciate me as a person, with the amount of fun I’m having while I work, the surfing, the chatting, the blogging, do they understand my working hours, the limits of my creativity, can they handle the people skills I have or lack?
In fact, these would be good criteria to consider before hiring *any* developer. But how many companies will consider these issues? And even if you cared, how would you measure them, or verify the claims? In fact, you’ll need to have prior experience of working with me.
This takes us back to working together on free software projects. You will know what kind of stuff I do by working with me. And with time, you’ll start to trust me (or not, haha). Working together is the only way of earning trust.
Back to enterprise software: IT company basically don’t trust developers, and the clients don’t trust the IT company. Thus, they fix dates and prices, and the developers set to work. Constraines by time and money, and not free to develop what they enjoy most, developers are slowly turned into code monkeys.
I don’t think we can do anything about it.
Enterprise software turns us into code monkeys.
This is a long post. Sorry about that. I should shorten it.
I’m trying to ramble, too, in my attempts at finding the right mix of PlainTalk and brevity.
#Software
(Please contact me if you want to remove your comment.)
⁂
Nice post. Longer that your usual ones but you *do* make a good point about trust.
I also think that free software developers try to gain the trust of their users. If they try to ship something under the hood, they know that people can look at their code and that’s their doom. The culture generally improves.
– NoufalIbrahim 2005-04-24 14:48 UTC