Saturday, May 1, 2010

Insane Complexity

As a user, it is nice to have software features. Well, it is nice if they are actually accessible. Lately, I seem to be engaging with a lot more software that is feature-rich, but nearly impossible to use.
  
It feels like the programmers have become so excited about adding new things that they've forgotten to add them sensibly. A thousand features are no good to me, if I can't use them. They're no good to me, if I have to read pages and pages of badly written instructions, or pages and pages of web forums complaining about problems. They're no good to me, if I can't even guess at whether they exist or not.

Software plagued with too many features crosses over into "insane complexity". It is so horribly over-complicated that all of the extra programming effort to add this stuff is effectively wasted. It is unusable.

There are so many examples to choose from. I'll pick some easy ones. Most Microsoft products are feature-rich, but obtuse. I've seen several nasty products come from IBM as well. The old mainframe systems are a labyrinth. Even Unix, which started life as being consistent and philosophically driven, has really descended into chaos with spin-offs like Linux. The list goes on, and on.

Users don't want to be presented with large screens containing a million options. They don't want a million little tiny controls. Most of the time, they don't want to "tweek" their installs. They're not interested in the super cool ways of doing things, and most of them hate having to fiddle with any poorly named config parameter. As a user, all we want is something that is simple to setup, simple to use, and that works correctly. Great big drop-down menus of useless, obscure features are depressing. They're intimidating. They are not good design, and they aren't appreciated. Command line tools with a million arguments are hopeless too. There is just too much "stuff" to bother with.

It is easy to write a few lines of code that works. It is easy to add a menu item to an existing interface or add a parameter to the command line. It is easy. There are a huge number of people that can do this; that can brutally extend some existing piece or create something small that works. This, however is not good software development. It is equivalent to just gluing a garden shed onto the side of your house, knocking a hole in the wall and then calling it an "extension". It is hacking. It may seem constructive in the short run, but ultimately it is gradually taking away the existing value of the effort. It is a -1. Negative effort.

Programmers often get so excited about their "chance" to create new features that they forget about the the users. This lack of empathy, shows over and over again in our modern creations. Every so often, a few new technologies will come forth like the iPhone, with simple interfaces, clean lines and easy usability that remind us that 'simple is possible'. That our ugly massive constructs, needn't be so convoluted. It just ain't necessary.

But while simple user interfaces get high praise, we can't forget that they are the 10% of the iceberg that is most visible. What lies beneath, in terms of configuration or operation, also gets ugly. And what lies beneath that, the code itself, is ugly too. Generally, the sins of the coder propagate upwards, eventually polluting the user's experience. What starts as a bit of disorganization before a hasty release gradually spawns into a complexity explosion. Software arcs. That is, once it gets going, it gets better for a while until it gets to the hump. From that point onwards, each new version is worse than the previous one. It's the software equivalent of 'jumping the shark'. Generally for most products, once they've started this downward spiral, they stick to it. It is a nosedive.

As an industry, we are definitely in trouble. The 'software crisis' which began almost immediately, over fifty years ago when the industry started, gets worse on a daily basis. Access to free and open software simply accelerates the problem. Programmers can now toss in so much useless functionality that it is sometimes impossible to determine the purpose of the code. The "all singing, all dancing" software, that is also cryptic, is useless. Adding features doesn't make it better. Adding features doesn't make the core work. Adding features that are inaccessible doesn't actually solve the problem. It just wastes time, and makes it worse.

I don't want features any more. I don't want options. I don't want to have to read a dozen pages of text to "grok" it. I just want something simple, that works.

2 comments:

  1. I have to agree with you. Software, as a System, does not just consist of the actual executing code itself; it is the combination of the product experience, full life-cycle, documentation, performance, quality, and many other things that constitutes a system.

    But we, developers, usually only focus on the 'functional requirements' or the 'features' of it. We even have buzzwords like 'feature-driven development' !

    For some time, I am attending a training course on "Systems Engineering" and it encouraged me to look at software from a system-of-systems point which now I think should be the standard approach thought in the CS/CE departments.

    It should be noted though, that this is not simply the guilt of the developer, but more so, of the project manager, systems architect and sometimes even the customer. They are the people that should have formed an appropriate set of features to be developed in the first place. Of course I am talking about mid-to-large projects here.

    Thanks for that insight...
    madchuckle.blogspot.com

    ReplyDelete
  2. Hi Cagil,

    Thanks for your comments. I saw your blog, it looks great, keep it up. We need more programming/software blogs.

    On most projects I usually try for a split position between being the software developer and being the project manager (at least for the technical/analysis parts of the project). In that way, I can control the release dates, scheduling and feature sets, to make sure that we don't accidentally walk into a death march, or start building out of control. The split role is much harder, but I think a lot of projects would go better if they were lead by experienced (and practicing) developers, not experienced project managers.

    With customers, I know a lot of developers take what they say at face value, but I tend to try and read between the lines. I don't want to know their solution, I want to understand their problem. They are the experts in their domain, and I should be the expert in providing a workable software solution. The choice of features, scope, data, technology, etc. should be the developers, although I've seen a lot of people over the years punt this back to the users or to management.

    Unfortunately our industry doesn't value experience very well. Young programmers are less than half the price of old ones and easier to manipulate, so many projects are staffed with kids. Kids can code, but they lack experience with architecture, and they can't lead. They just don't have enough experience to know what they should do, as opposed to doing what they are told, or what they incorrectly think is right. Because of that, you get disconnected managers leading teams of kids that don't know any better. It is the perfect recipe for disaster, which is usually how it ends.

    I really think that the experienced (and rare) developers know enough to step forward into the larger roles in their projects. If you have the background and experience, you are far more likely to steer the project away from a cliff. If not, you're just relying on luck.


    Paul.

    ReplyDelete

Thanks for the Feedback!