But, don’t mistake my belief in opinionated software to mean that I like the opinions of all opinionated software.

For example, Git is very opinionated software, but I don’t care much for it. Git was created to solve a specific problem, and consequently Git values strong support for non-linear development, distributed development, efficient handling of large projects, and fast merging of patches from email. As it turns out, my source code management needs have almost zero overlap with those features so Git is not a good fit for my development workflow. I recognize that those features are important to many projects, but they aren’t for me. Git can be exception at what it does because it doesn’t compromise to try to meet my needs, too.

And here’s the best part: I don’t have to use Git. If it’s opinions don’t mesh with mine, we can agree to disagree and I can choose a tool better suited for my needs. Some commentators seem to miss this point. Opinionated software doesn’t preach “one true way”, it says “my way or the highway”—if my software doesn’t work for you, you’re free to find another solution that does work for you. (In the open source forums, this sentiment is echoed as “if you don’t like it, then fork it or build your own”.)

The article really hits its stride in the section “Creeping bureacracy”. If you’re short on time, jump down to that header. I found myself laughing and nodding at these pearls of wisdom:

I think that by far the biggest reason that C++ and Java are the predominant industry languages today, as opposed to dynamic languages like Perl/Python/Ruby or academic languages like Modula-3/SML/Haskell, is that C++ and Java cater to both secure and insecure programmers.

and

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done. It’s not very easy to drag your heels and dicker with class modeling in dynamic languages, although I suppose some people still manage. By and large these languages (like C) force you to face the computation head-on. That makes them really unpopular with metadata-addicted n00bs.

While the whole article sent my neurons firing off in dozens of different directions worthy of blog entries, I’m going to concentrate on this bit:

Java has been overrun by metadata-addicted n00bs. You can’t go to a bookstore or visit a forum or (at some companies) even go to the bathroom without hearing from them. You can’t actually model everything; it’s formally impossible and pragmatically a dead-end. But they try. And they tell their peers (just like our metadata-addicted logical data modelers) that you have to model everything or you’re a Bad Citizen.

Hello, my name is David and used to be a metadata-addicted n00b. Joking aside, Steve is absolutely right.

I think Java became the garden of frameworks due to its early positioning as an enterprise software platform. Enterprises are strange beasts. Internally developed enterprise software has a tendency to live a long, long time. A decade, often more. Take a moment and pause to think about what you were doing 10 years ago today, and then think about how much technology has changed in that time, too.

One of the problems faced by enterprise software that isn’t typically encountered outside of enterprises is that the systems, protocols, and interfaces that an application was originally written to run on or collaborate with will have been replaced. Vendors are replaced, authorization systems change (database to directory to single sign-on), databases are upgraded, CORBA loses favor to EJB and then to SOAP, and so on. Consequently, the fathers of Java emphasized abstraction—don’t get too close to your touch points, because they may be changed tomorrow. Let’s call this “abstraction at the edge”.

I think that a lot of Java developers—myself included—took abstraction too far. Instead of abstracting at the edge, we started abstracting everything. Rather than creating opinionated software, the Java development community promoted and embraced frameworks that competed to be the most general and all-encompassing. Rather than solving problems, the Java community invested its energy in building problem-solving engines.

This is important because as Java developers have started jumping into new communities—I’m thinking of .NET, Flex, and Ruby on Rails—they have brought their framework addictions with them. NHibernate and Spring.NET are gaining momentum within .NET communities and you can’t look sideways at Flex without tripping over a new Flex MVC framework¹. The Rails community has been very successful at resisting the inventions of “metadata addicted n00bs” because the big names in the community have taken a strong positions against abstraction.

I might be growing up faster than Steve’s timetable for growth, but I’m tired of frameworks that try to do everything. I just want to get things done.

¹ Here’s nine for you: Cairngorm, PureMVC, ARP, MVCS, Flest, Model-Glue: Flex, ServerBox Foundry, Guasax, and Slide. List compiled from here and here.

Of course, people don’t want to hear me say that they need to test their UI. And they definitely don’t want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support. The general idea seems to be that real programmers can’t be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.

Software exists to solve problems. To understand the problems a proposed software application is supposed to solve, nothing beats walking a mile in the user’s shoes. (37signals calls this What’s Your Problem? in their book Getting Real.)

So I subscribed to everything. If I read a couple of articles from the same source that were interesting to me, I would subscribe to that source’s feed. Over the course of a year, this lead to me be the proud subscriber to over 400 feeds. Many of the feeds published content daily or even more frequently. I grouped the feeds into categories like “Must Read”, “Should Read”, and “Read If I Have Time”. I quickly fell behind and after two years, I had over 3000 unread articles.

Feeds were a fire hose and I couldn’t take it. I needed to reassess my relationship with feeds. Instead of subscribing to everything of interest, I cut back — way back. I unsubscribed from everything and waited to see what I would miss the most.

Turns out, the two feeds I missed the most were John Gruber’s Daring Fireball and 37signal’s Signal vs. Noise. Both of these feeds publish up to several times a day, but Gruber’s posts tend to be extremely short and I didn’t have any concerns about being able to keep up.

After a while, I found (or rediscovered) other feeds that were interesting. Should I subscribe? I needed a heuristic. Only subscribe to feeds that post less than once a day. Actually, about once a week is ideal. I found that feeds posting more frequently are trying to cover news in realtime. My Twitter community fills that need nicely, so I don’t need to overwhelm myself with feeds that repeat what I already know.

It’s been three months since I’ve adopted the heuristic and I’m up to 15 feeds. I’m always up-to-date and I feel in control of my experience. I look forward to reading my feeds again.

Like many other design books, Designing the Obvious cautions developers against designing applications with the bells and whistles developers appreciate because most users aren’t at all like developers. In Hoekman’s own words:

Programmers… often want incredible amounts of control over the applications they work with, so they surface everything they can in the applications they build… Their users don’t want this fine level of control. They want to understand how to get their work done and go home…

But what do I do if my users are developers? What if I’m building software for use by development teams to adopt the enterprise’s release management services? To what degree does the above advice still apply?

I think the advice should still be followed more than it should be ignored. I don’t know any developers who got into the industry because they loved release management processes, and I think it’s fair to say that most developers view such processes as barriers or hurdles that stand between them and what they want. The developers I know (including myself) approach release management software like most people approach tooth extractions or prostate exams: at best, they just want the whole experience over with as quickly and painlessly as possible; at worst, they deeply resent it. Consequently, software that facilitates release management processes should probably be as demure and unobtrusive as possible.

(Naturally, I’d like the software I write to have a better reception than “gee, that wasn’t as bad as it could have been”. I have some ideas that I’m hoping will kick the user experience up a notch. We’ll see how that goes.)

Now, back to the rub. What do I do about a ticket to make the number of items on a page a user-configurable preference? (Does this sound familiar? It should.) Contemplating such a ticket started my thinking about how to design for developers. Should this be a preference, or did I just not pick a good default? Developers love to control little things like this, but does it matter? What is the value of this feature (as measured by anything: cost savings, productivity gains, user satisfaction, whatever) versus the cost of implementing and maintaining it?

Each time you say yes to a feature, you’re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature’s out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get. [From Getting Real]

After kicking this around in my mind for a while, I realized something: a ticket to make items-per-page a user-configurable setting is a feature request, not a use case or user story. Why does it matter if there are 20 or 50 items on a page? How often is the 21st item in the list the one a user really cares about? What problem is this feature trying to solve? What is the user trying to do such that having more (or fewer) items on a page will improve her productivity?

I’ve come to the conclusion that feature requests are an anathema to our profession. Features are the how of application development, and we often get so wrapped up in them that we lose sight of the why of application development. There is a trap into which it is easy to fall: “just add a button to…” or “move that to here” as deceptively simple and some even sound almost like a use case, but they aren’t. Features should be driven by use cases or user stories—features should directly contribute to helping the user be more productive. A feature should be functionality identified by the development or design team as a means to assist a user toward a goal. Everything that doesn’t directly assist the user to achieve an outcome is simply a distraction with a maintenance bill attached.

The first items aren’t that interesting. A 360|Flex folder and an Effective UI graph pad I picked up off a table while at that conference (thanks, guys!). I plan to use the graph pad to layout some screens for an upcoming project at work and want to keep it handy in case inspiration strikes. I’m still waiting for that inspiration.

Then I pulled out a two inch thick collection of papers I’d printed (duplex, to conserve paper). On top of the stack is D-Click’s Adobe Flex Coding Guidelines. I really don’t like placing opening braces on their own line. Drives me nuts. (For my money, the Sun Java Coding Conventions can’t be beat.) But, when in Rome, do as the Romans do. I recognize that being consistent (especially across developers on the same team) is more important than the merits of any single convention, so I’m trying to learn new habits.

Next up are printouts of six chapters from Adobe’s Building and Deploying Flex Applications (PDF here). I have only built Flex apps inside of Flex Builder, so I still need to learn the command line tools. My company is big on “repeatable builds”—meaning that any interally-developed production applications should be easy to regenerate from source without developer involvement. In practice, this means that the application must be built with a command line build script (Make, Ant, etc.). Besides, I get nervous when I’m overly dependent on an IDE. I like code completion, syntax highlighting, and refactoring, but I really like to know that I can do it all from vi or Notepad and the raw Flex SDK if desired or needed. Hence my interest in the Building and Deploying Flex Applications book. And I mean book! A full printout would weigh in at 400+ pages! So I picked the most important parts to me and just printed those.

The first chapter is Chapter 3 (Flex Application Structure). I just finished reading this chapter last night. Not a lot to say here. It’s good to have the layout with which I was familiar due to Flex Builder reinforced in print. Next up are Chapter 4 (Applying Flex Security), Chapter 7 (Building Overview), Chapter 9 (Using the Flex Compilers), Chapter 13 (Using ASDoc), and Chapter 14 (Creating Applications for Testing).

Then I come to printouts of various O’Reilly articles about Ruby on Rails that I intend to read Any Day Now™. Rolling with Ruby on Rails Revisited, Cookin’ with Ruby on Rails: May, Cookin’ with Ruby on Rails: Designing for Testability, Cookin’ with Ruby on Rails: More Designing for Testability.

And finally, I have Greg Hamer’s presentation slides for introducing Cairngorm at 360|Flex. I suppose I can take this out of my bag. I have the general idea of how Cairngorm works. I’m still waiting to write an app large enough to make playing with Cairngorm worthwhile. Okay, that’s not quite right. I’m still working on my first Flex app ever. I’m plugging into the 37signals Backpack API. When I’m done with that, I might look at refactoring it for Cairngorm just to get that experience under my belt.

And that’s wy my computer bag weighs a ton. What’s in your computer bag?