Pinderkent

Early last month I gave my opinion about some OpenOffice.org UI prototypes. In short, I wasn't too impressed. Unfortunately, we now see similarly flawed ideas coming out of the Mozilla Firefox camp with their "Windows Theme Revamp" project.

Take, for instance, this proposed design for the Firefox 4.0 UI. I do realize that it's a very early proposal, and will likely be subject to much change. However, it looks to me like it's heading in a very bad direction from the very start.

My main complain is the complete lack of consistency we're seeing. Functionality that was previous organized in a sensible and accessible manner within menus and toolbars is now spread out haphazardly throughout the top of the window. We have buttons to the left of the browser tabs, along with some to the right. Within the buttons to the right of the browser tabs, one button looks like a browser tab, while the other doesn't. We have various kinds of buttons around the URL bar, and some within the URL bar itself. Then there are what seem to be "Page" and "Tools" dropdown menus at the right-hand side. While likely similar in functionality, these dropdowns and buttons just aren't graphically consistent with one another.

Something that recent UI designers seem to forget these days is the benefit of textual labels. Traditional menus often do a good job of using text to explain the different actions that are available. These days, however, we get icons that probably were descriptive to the designer, but don't mean a damn thing to many of the users stuck using their design. At a glance, I have no idea what clicking on the hat-shaped thing next to the "+" tab in the tab bar would do.

Another uncertain aspect of the design is what clicking on the button to the left of the "Page" dropdown would do, the one with the picture of a book containing a star. I assume it involves bookmarks, but would that bookmark the current page, or would it just expand the dropdown? That isn't clear from just looking at the button. It also isn't clear what the relationship is between that button and the star within the URL bar is. Contrast this to the "Bookmarks" menu of Firefox 3.0, which by its label clearly indicates that it involves bookmarks, and has a very clear "Bookmark This Page" item at the very top.

I'm not sure what drives these UI designers to create these completely inconsistent and unfriendly user interfaces. It's almost as though they're trying too hard. They're making changes and breaking with tradition not to truly improve the user experience, but rather just to be "different". And that's not the way to go. It's good to be different when those differences bring some benefit. Unfortunately, we just don't see that with the differences proposed in the recent OpenOffice.org and Firefox 4.0 design proposals. As a user of both pieces of software, I hope that these design proposals don't become reality. They'd seriously hinder the usability of those applications.

Today I read an article written by Davy Brion a few months back. It talks about his experiences interviewing several developers, and some of the techniques and concepts that some of the candidates were and weren't familiar with. Namely, he found Java developers to be more familiar with dependency injection, inversion of control, test-driven development, aspect-oriented programming, object-relational mapping, and so forth. While he seems to see such knowledge as a benefit, I'm not so certain it truly is.

The Java community is well-known for their adoption of design patterns and frameworks. One of the most popular frameworks is the Spring Framework, which offers an IoC container, an AOP framework, a data access framework, and so on. AspectJ is widely used for AOP. Many projects use the Hibernate ORM library. And JUnit was integral in bringing test-driven development to the mainstream.

However, various notable software developers have suggested that design patterns are merely missing language features. In many cases, this does appear to be the case. Some common features and techniques of functional programming languages, for instance, render many design patterns irrelevant.

Unfortunately, design patterns and various frameworks have become quite embedded within some portions of the wider software development community. The devotion that some developers have to the "cause" can best be described as a religious in nature. It is particularly strong within the Java community, and to a lesser extent (usually Java expats) within the .NET community.

For every case when I've seen a techniques like IoC or DI used sensibly, there are many, many more cases of systems I've dealt with where they've became huge obstacles and only served to unnecessarily complicate the software system. The use of ORM systems is another frequent problem area. The first major problem that arises is usually performance-related, with the object mapper sometimes generating some truly horrific database queries, or bringing back huge quantities of data that are never used. In short, what was meant to save time ends up wasting it.

We often see these problems arise with business software. Often times, this sort of software is relatively simplistic in implementation, with most of the complexity coming in the various and often inconsistent business rules that need to be supported. So what I think we've seen in many cases is software "architects" who feel the need, for whatever reason, to build horribly complex systems where they're not needed. Design patterns, along with the copious use of frameworks and over-generalizations, facilitate this sort of development.

Soon, what should be simple systems quickly explode in complexity. The quality of the software drops, even though there may be a huge number of automated unit tests. Usability becomes a nightmare. Simple maintenance tasks and bug fixes take far longer than they should, because the developers need to unravel unnecessary abstractions.

Some of the most successful business software systems I've dealt with have evolved over time, often with different parts being written in isolation from one another. The only "frameworks" used were developed in-house, tailored specifically to the problems at hand. Any "design patterns" used were those that were observed naturally occurring in the software system as it grew. Instead of trying to provide overly-abstract and highly-generalized "solutions", each part of these software systems performed a very specific role, and did that role well.

So if we feel the need to start explicitly using design patterns or frameworks for our software, maybe we should take those feelings as a warning alarm. Finding a more powerful and expressive programming language may be a good place to start. After that, the reasons for employing design patterns or frameworks should be considered very carefully. It often ends up being quicker and easier just to sit down and write the software, rather than planning and debating and designing it. This is especially true if such techniques are used merely to add complexity to what should be a simple system, just to make it more challenging for the developers.

James Hamilton recently wrote about the use of low-cost and low-power servers, with a focus on ARM-based systems running Linux. He points out that the linux-arm.org site itself is running on such a setup. Looking at the specs of their systems reminds me of the servers we used in the mid-to-late 1990s, and even into the 2000s. Having been involved with software development for many years now, with much of my work revolving around networked business applications and server applications, I find this to be an interesting topic.

Clearly, a huge part of the problem today is the software we'd be running on such hardware. With the rise of Java, and especially frameworks like Ruby on Rails, far less of our hardware resources are used for actually performing the work of our software applications, and instead go towards powering the numerous frameworks, virtual machines, and platforms typically underlying our applications. Indeed, it has gotten so bad that some people are surprised when their Ruby on Rails-based Web application can handle "multiple requests per second", on modern hardware, without exhibiting performance problems.

Most recently, I wrote about Stack Overflow's outrageous hardware usage. Give the generally simplistic nature of that site, and the huge amount of processing power offered by today's low-end hardware, it's almost absurd to see how much they're apparently using.

When discussing lightweight servers, we shouldn't forget to consider the use of NetBSD instead of Linux. Aside from it already offering several ports to various ARM-based platforms, NetBSD is among the highest-quality open source software out there. I know of one person who used NetBSD on old PCs to serve images. I've also advocated it as an alternative to lightweight Ubuntu Linux distributions, as well as for use on low-power systems like Intel's classmate PC.

People today seem to forget just how powerful a typical server is today. Even the ARM-based servers that James mentions, or those powering the linux-arm.org Website, sound much more powerful than what we used a decade ago. That's not unexpected, of course. The cost of hardware rapidly drops, while its capabilities rapidly increase. Unfortunately, our software systems seem to eat up those gains rather quickly.

The main barrier to the widespread use of low-power and low-cost servers will likely be our existing software, frameworks, and platforms that use hardware resources very inefficiently. Instead of trying to salvage those, many of which are already a lost cause, perhaps we should be more willing to start from scratch, strip out all of the unnecessary layers of software that have accumulated, and make better use of functional programming languages like Erlang and Haskell. So not only would we get the benefits of using more efficient hardware, but we'd also get a much simpler and efficient software platform upon which to build our applications.

Joe Stump recently wrote about why he switched from PHP to Python. What he says is absolutely true. He nails down many of the problems with PHP, and also lists many of the benefits of Python. In the end, however, I think we can just sum up the comparison between the two languages as being one of comparing Python's professionalism versus PHP's amateurism.

When I describe Python as being professional in nature, I am referring to the emphasis on care, contemplation, quality, and doing-the-right-thing-even-if-it's-difficult we generally see embraced by the Python community. Like Joe mentions in his article, the language itself exhibits a high degree of sensibility, consistency and predictability. It has clearly been carefully evolved and grown, rather than having features and functionality tossed on here and there. It's a language developed by people who know what they're doing, and it's a language used by people who know what they're doing.

On the other hand, we've seen much of the opposite out of the PHP community. The language itself is a good testament to the general preference of that community towards doing things quick-and-dirty, rather than correctly and with care. It's full of quirks, it's inconsistent, and generally a jumble of differing ideas and philosophies. We've seen this happen with its standard library, as well. With the core platform having such poor quality, any software build upon it typically ends up suffering from quality and security problems, too.

It's no wonder that so many developers are moving away from PHP towards better languages and environments like Python and Ruby whenever possible. PHP is deceptively attractive. Sure, it's widely supported, and yes, it's got a large standard library. But it has many hidden and not-so-hidden costs, including horrid maintainability of applications written in it, numerous security flaws within critical code, and numerous hurdles towards developing decent software. Even if the perceived costs seem higher when using a more professional language like Python, in the long run it becomes the only viable choice when the alternative is something as amateurish as PHP.

While some descriptions of pair programming suggest that "all code to be included in a production release" is to be developed jointly by two programmers working in tandem at a single computer, that isn't a steadfast rule.

Teams wishing to employ such a development technique can be flexible about their pair programming arrangements. One team I worked with in the past only chose to use pair programming while developing the most critical parts of their software system. This allowed for the core functionality to be well-understood by all of the developers, but as soon as that work started to stabilize, they each went back to working on code alone. But as soon as core functionality had to change, pair (or even triplet, in some cases) programming was used.

This proved quite effective. Code that the team agreed was trivial could quickly be developed by a lone developer without too much overhead, while more complex or critical changes still had the oversight and involvement of at least several team members. They managed to strike a very good balance, which allowed them to develop their software quickly and efficiently, while also helping to keep the number of bugs to a reasonable level.

Other teams using pair programming shouldn't be afraid to experiment with introducing some flexibility into their process. It is possible to practice pair programming even if it's only done some of the time, or even just when absolutely necessary. Given that each development team's situation and software system is different, some teams may be best of pair programming only 20% of the time, while others are best off pair programming at or near 100% of the time. It should be tailed to each team's specific needs.