Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
We’ve posted a luscious — dare we say lickable? — update to the look and feel of the infovark website. Thanks for all the help, rustybones!
Among the many changes Rhys made:
Tell us what you think: Leave a comment.
Hi. I’m Dean, and I was a maintenance programmer.
I’ve just spent the last two days refactoring the infovark storage and retrieval API. It wasn’t that anything was broken, exactly, it was just that it was… messy. There are a lot of things I should have been working on instead, but I couldn’t resist tidying up the object model a bit. It’s a weakness of mine.
You see, “maintenance programmer” is generally considered a pejorative label in the software development industry. Programmers that do maintenance — minor bug fixes, performance improvements, functionality tweaks — are generally on the lowest rung of the development team.
That’s how I got my start in software. My first coding jobs were technical support and troubleshooting gigs. You can ask anyone who’s worked with me on a development project, and they’ll tell you I’m fastidious — some might say fussy — about the structure of my code. And, truth be told, I’m picky about everyone else’s code as well. Since my first experiences with programming were maintaining large codebases written by other people, with no specifications or even a user manual to go by, I’ve developed certain habits of mind.
If great hackers are the poets of the software world, then maintenance programmers are the copyeditors. Great hackers produce elegant code. Their deeds are legend in the computer science community, and some have passed into history. Some are so good they’ve been celebrated in free verse. Their code soars in cathedrals of light, pure in its mathematical beauty.
By contrast, the code churned out by the maintenance programmer is solid, workmanlike, and perhaps unimaginative. But it works and will continue to work. There won’t be any odes sung to the maintenance programmer, but at least a few respected developers out there, like Eric Sink and Jeff Atwood, have spoken up for us. There’s even How to Write Unmaintainable Code, a humorous treatise on the many ways to drive a maintenance programmer crazy — and a tribute to all of us that have suffered at the hands of sloppy development techniques.
So we’re beginning to get some respect. And I’m proud of the work I do. I realize that being a stickler about naming variables properly or commenting logical branches only slows down development. But I take comfort in knowing that my code will stand up to some abuse out there in the real world.
Do you think you might be a maintenance programmer, too? Here are the seven warning signs:
Sound familiar? If you get the same feeling of delight at sorting out spaghetti code as you did reading Eats, Shoots, and Leaves, you might be a Maintenance Programmer. There’s good news for you, however: You’ll always have a job to do. Because no matter what happens in the computing world, there will always be code in need of a rewrite.
Jim McGee posted a list of essential Enterprise 2.0 articles to the FastForward blog. I’ve read many of them before but found a few items worth looking at again, as well as a few gems I’d missed. I’ve bookmarked it for future reference.
I’d also like to add a few other articles to the list. The first two have to do with managing collections of information. Information is the raw material knowledge workers process into insights, analysis, and innovation. In today’s environment, when there’s more information available than ever before, it’s worth spending some time thinking about how we collect and manage all that data.
The last link has to do with social networks and is perhaps more relevant today, post-Facebook, than at the time it was authored in 2003.
I’m sure I’ll think of more, but these are the most obvious and most readily available articles missing from Jim’s list. Happy reading!
I can’t resist adding my own thoughts about making Enterprise Software sexy. (Gordon posted his comments yesterday.) But in the grand old tradition of Web Pages that Suck, I’ll do it by talking about the many things that make Enterprise Software drab, dull, and difficult to use.
I call it the battleship gray syndrome. No pictures, no icons, no colors, and no frills: It’s spare, utilitarian, industrial. When someone says enterprise software, I bet you think of something that looks like this:
But why? Why gray? I’ll let you in on a secret: If you’re working with an application done in battleship gray, you’re not working with a finished product. You’re working with a prototype. Perhaps it was a utility written by someone in your internal IT department to scratch a particular corporate itch. Perhaps it was built by an outside consultant for a fixed fee. Maybe it was sold to your CIO, who wanted something serious and functional and cheap. You got ripped off.
The two most important of frameworks for enterprise applications are still Microsoft Visual Basic and Java. Both have a handful of pre-built widgets and controls that developers can use to rig up a working interface quickly. Programmers love this because it’s so easy to get to a working application. When the pointy-haired boss walks by with yet another lame requirement from the luser community, Joe Codemonkey simply drags another radio button out of the toolbox onto the page and writes a little code to wire it up. No sweat.
And no design, either. There’s a reason these pre-built widgets are battleship gray: They’re neutral. When developing a prototype, developers often deliberately make the colors fonts and icons as neutral as possible. This is to get the stakeholders that review the application to focus on the important part of the software from the developer’s point of view: the functionality. Joel on Software has a great article about this called The Iceberg Secret.
The idea is that once the functionality is complete — the hard part as far as the programmer is concerned — there will be time to replace the generic rectangular text buttons with something a little flashier. In practice, this hardly ever happens because all software products run late. So most standard corporateware consists of feature-complete applications with prototype interfaces: The battleship gray syndrome.
There’s also a more cynical reason for the battleship gray syndrome. Because the look and feel of these applications is entirely neutral, it’s really easy for consultants and vendors to repackage them and sell them to a different client. It’s often how these companies recoup the losses they incur creating custom software. If a vendor spent weeks getting exactly the right color red into an interface for Coca-Cola and then had to redo the whole thing in IBM blue, they’d never make any money. It’s far easier to do the whole thing in battleship gray and swap out the logo in the upper-left-hand corner.
Good software developers might protest that it’s easy enough to replace the standard controls that ship with development frameworks with custom elements. But even if diligent developers took the time and effort to build or buy custom interface widgets, corporateware would still look dated. The reason is that style trends evolve much faster on the Internet than on an enterprise intranet. The Internet is a giant clearinghouse of design ideas. We can see what works, what doesn’t work, and most importantly from a developer’s point of view, we have access to the code that created it. Good design elements introduced on the Internet are rewarded by the sincerest form of flattery: they are imitated. By contrast, updates to the look and feel of most enterprise software are glacial by comparison.
Try this experiment: In the next enterprise software RFP your organization puts out to tender, include the requirement, “User interface must be beautiful, elegant, and intuitive.” Watch the enterprise vendors that respond jump through all sorts of hoops to get that requirement removed from the specification. Software vendors hate requirements like this.
Supposing the vendor’s sales guy is desperate for his commission and passes it off to the services team as an implementation issue, the vendor’s project manager will begin furiously down-scoping the requirement. Good project managers are on the lookout for subjective requirements like these. They’ve been burned in the past by customers that refused to accept the final product, so they’ll make sure that the requirements are discrete and measurable. They’ll try their darnedest to re-set expectations. They won’t accept a requirement like that on a fixed-price contract again. No way.
It’s not entirely the vendor’s fault, however; your own organization is partly to blame. Good design takes experimentation, iteration, and talent. That means high salaries and a time-and-materials contract. But you’re on a budget. Sure, the marketing guys can blow millions advertising to customers, but internal systems for employee use will never get that kind of funding. So as soon as you get something working, you accept the product and leave the design and usability bit for next year’s budget… or maybe the year after…
Which brings me to the last point, which is that enterprise software is dealing with a captive audience. Employees must use employer-provided tools, such as they are. In the consumer software market, an individual is always free to try something else. And with today’s Internet applications, the costs of switching are lower than ever before. Remember Friendster? MySpace? Despite the fact that consumers poured hundreds of thousands of man-hours into building up those communities, Facebook drew a huge crowd once it came on the scene.
Scoble fired a torpedo off the bow of enterprise software. He wants to sink the battleship gray syndrome. Judging by the response in the blogosphere, so do a lot of other people.
Our approach is to borrow whatever we can from the design lab of the Internet, applying those tools and techniques to the problems that face the enterprise. Our approach is to sell and market our software in a different way, direct to the knowledge worker. And our approach is to put design and usability at the forefront, rather than leaving it as a “nice-to-have feature” that we’ll implement “if we have time.”
The blogosphere exploded over the weekend with an exciting conversation about enterprise software.
The comments stem from Bill Gates, talking about the future of Microsoft, but the controversy was stirred up by Robert Scoble, who asked his readers how to make business software sexy?
Some of us who actually do this for a living took that to heart. Michael Krigsman attempted to explain the innate differences between enterprise and consumer software, only to be rebuked by Nick Carr:
“By perpetuating a false dichotomy between the friendliness of consumer apps and the seriousness of business apps, all that Krigsman is doing is giving enterprise vendors cover for continuing to produce software that’s difficult and unpleasant to use.”
But my favorite post so far came from SocialText’s Ross Mayfield:
“Enterprise software can do better. In fact it has to, because of broader competition. At least with basic usability. … Step out of the feature matrix. Also recognize that control instincts lead to unusable crap that is a barrier to collaboration. And every enterprise software app is a collaboration app, otherwise it’s infrastructure”
We all know a lot of enterprise software is horrible to use. It’s complicated, frequently counter-intuitive, and often requires extensive training.
Most people who use it daily don’t like it. They certainly don’t love it. Compare and contrast the following Google Searches:
“I love Facebook” vs. “I love Oracle E-Business Suite Financials”
We’ve talked about this a lot in the past, so I’ll try to keep this brief… How can we make enterprise software sexy?
Design it for People to use.
Enterprise Software is currently not designed for people to use — it’s designed to be bought by someone in senior management.
(Which is always good for the software vendors, but not always good for the enterprise, and rarely good for the people who happen to work there.)