Dead Paradigms in Applications

You know what I am talking about, and you have to admit that it is getting a little sad: they are some of the most ridiculous design patterns in software that are no longer required by physical or operating system demands, but they are still around. Lazy developers and designers are opting to copy old patterns rather than creatively make use of new opportunities.

And that is what it is, laziness. Plain and simple. Welcome to Dead Paradigms, cousin and glasses-wearing cohort of Dead Media.

Web based “collaboration” applications are some of the worst offenders here. Each one is a little funeral for old ideas on a new medium.

The culprits?

The Team
The concept of a Team is useful in, well, amateur sports. You want to practice together, build camaraderie and learn to trust eachother. The Team breaks down in every sport eventually however. Professional athletes sign individual contracts, become free-agents when they are able and simply go to whichever team will pay them the most.

Professionals should act similarly within their organization. Having pre-defined teams, or groups, or any other artificial designation is an easy way of not having to deal with human nature — which is to be far more independent and transient. It is a transference of corporate structure in to your software. Aren’t you building software to solve a problem, rather than reflect a problem?

Projects
Tagging helped murder the Project, but it is still hanging around. Projects have defined beginnings, ends, tasks, milestones, participants and required results.

Real work does not happen in projects. Projects are what people do when they aren’t doing anything useful.

Real work is ad-hoc. It takes place when it is needed and it involves only those who need to be involved. Really great work however, is open to everyone.

Projects counteract this. They put up walls around what might be really great ideas. They define who must work on the idea, even if that person is completely disinterested.

Projects can be measured, I concede, but it turns out that ad-hoc groupings are even easier and more valuable to measure. Because measuring the success of a project can only result in an expected outcome, there is little room to identify patterns, trends and to foresee new needs for the organization. Measuring and analyzing ad-hoc work and groupings is key to moving an organization ahead.

Permissions
Sometimes they are just a manifestation of Teams/Groups, but more often they are provided as a sort of beaurocratic lithium designed to appease the masses.

There are a few problems that flow from implementing rigid permissions. The first is that you aren’t just defining what items are protected, you are defining how people can do their jobs. In industrial-productivity models, we want to limit options in how each person can do their job. By limiting what they do, and how they do it, we can increase output-efficiency. Modern organizations have far more complicated needs however, and by increasing the amount of permissioning taking place, you are removing opportunities for self-directed and competent individuals to do their job, which can be many things in many places. These are the same people who will detest having to ask to have their permissions increased.

And even more toxic paradigm is Visible (post-action) Permissioning. This occurs when you allow an individual to see that an item or resource exists, but you then block their access to it. Post-action permissioning is the pinnacle of laziness. It shows that you do not have any appreciation for the end user.

The File
Do I have to say much here? Creating a File, Saving a File, Sending a File. It’s the one thing that isn’t going to go away for a long time, but it is dead dead dead.

I create content. Sometimes in little bits, sometimes in bigger pieces.

The Page and The Document
In my mind, blogging killed both the Page and the Document. Wikipedia uses the page well, but murdered the Document in cold blood.

A Page does not exist, in case you are wondering. It is a figment of your imagination. It was first required when we had to limit the size of the press. Before that, parchment could be as big or as small as needed. Before that, you certainly didn’t make a stone tablet in standard sizes. That was wasteful.

So, why are you aiding and abetting the creation of Pages in your applications? Especially your web applications? Help users create bits of content and help them knit them together.

Save Button
What should a user have to Save that you shouldn’t have already saved for them? Now that PCs have 100 or more gigabytes of hard-drive space, and servers have terabytes of cheap data storage, you can afford to just Save whatever the user is working on. They don’t need to name a file, you can name it for them. They don’t need to remember where they put it, the user can just use Search to locate it.

Configuration
Applications have to start learning as they go. If the user clicks on a particular item every time they use your application, why not make that easier for them?

Applications are getting better at this. Gmail does a great job of learning who your contacts are. What opportunities are there for your application to learn from those who know best, your users.

You think you are smart and can make these decisions for them, but if you were really smart you would make software that could learn. That is what a great teacher does after-all, they teach their pupils to learn.

6 thoughts on “Dead Paradigms in Applications

  1. Pingback: socialwrite.com
  2. Hey Jevon, I liked this article — forced me to re-evaluate a few things with regards to ThoughtFarmer. Also reminded me of the “SUGAR” O.S. created by the One Laptop Per Child project. Blogged about it here.

Comments are closed.