Tuesday, July 31, 2007

Large Monolithic Applications Must Go...

There's simply no way that a single team of analysts, architects, program managers, designers, engineers, programmers, testers, and users can produce a large monolithic application from scratch without incurring a tremendous expense of resources. Moreover, there is a huge amount of history and effort buried into every single mainstream application that would cost a fortune to replace. The pace of development of such applications must inexorably grind down to a halt. Large monolithic applications are about as agile as molasses.

So... don't build monolithic applications!

Monolithic applications are characterised by their attempt to control the whole state of the world. They generally suffer from the inner platform problem as they try to unite objects, actions, preferences, views, controls, tools, and affordances under a common shell. This way lies madness!

Pretty much every monolithic application ends up going this way. Architects agonize over nuisance details involving how to abstract component interactions into the shell. Large refactoring efforts and attempts at pluggable architectures only forestay the inevitable for so long. Eventually we end up with an entire tool-chain, perhaps even software factories, all wrapped up in and around the problem of managing an exponentially increasing number of component interactions. An enormous investment of engineering resources is poured top-down into the shell!

This approach is incredibly wasteful! By and large, software teams around the world are tackling the same problems, encountering the same road-blocks, making the same mistakes, and never quite getting all the way there. There's too much micro-management and too little reuse. Why should anyone ever be forced to design a new plugin component model, dynamically populated toolbars, key binding management, system preferences storage, software updaters and all of the other bits and pieces you need in a real large scale application? This stuff has been done 100 times. Look at Eclipse for example.

Monolithic applications must go! Consider dynamically assembled interoperable object-centric or service-centric models instead. Why should you even need to care that you're working inside an "application" when you're really just trying to perform some task. Don't expect future UIs to look or work at all like the walled gardens we have today!

I firmly believe today's development model is broken and unsustainable.

Stealth mode.

Wish I could talk about what I've been doing with MbUnit lately. I can say that I stayed up until 5am the past two nights and was very happy to type "svn commit" on the next milestone...

What about UI design?

<another-rant>

It sometimes seems that most everyone out there still trying to sort out which flavour of MVC is best for certain kinds of apps and tool chains. Lots of very smart people have lent their insights to UI architecture, implementation, verification, and maintenance.

Some amazing things have come from this effort. It looks like we're finally starting to wean people off of the tightly coupled View-is-king mentality that has ruined so many programs. I have long despaired that (for better or for worse) the invention of the Visual Designer had obliterated the value of solid software design skills in the name of WYSIWYG and drag-n-drop.

But there's still something missing. Most of the MVC effort has been directed at the plumbing end of the works. Less efforts seems to have been devoted to synthesizing better approaches at designing UIs themselves. Most GUI toolkits approach the problem from the perspective that the UI designer knows exactly which buttons she wants to put on the screen and it's just a matter of painting them in the right location and wiring them up. But it takes a lot of skill to provide buttons, dialogs and preferences for every conceivable reasonable thing the target audience might want to accomplish.

Frankly, despite great advances in tooling, most UIs still suck. While we're busy building frameworks and arguing points of architectural finesse, the world is being smothered in confusing, brittle, inflexible and non-interoperable applications. It's no wonder many people are still afraid of computers. We must attack the very essence of the UI design problem. Plumbing won't get us out of this mess!

</another-rant>

Roll your own MV-Something!

<rant>

It seems everyone is coming up with fishy definitions of MVC these days. (NB. I am borrowing Andrew's links.)

There are many variations. For a couple of years now, blogs and newsgroups have been all aflutter about MVC for the Web and how fabulous it is. There's a little fuzziness over the exact role of a Controller so some variants use other terms like Presenter instead and even rearrange the triad a bit. Great! So now everyone believes at least that eMMM Veee Something is the next best thing since sliced bread. Maybe there's hope for maintainable UI design.

The trouble is, there's misinformation floating around. There are dozens of Roll Your Own MV-Something frameworks. Some of them are quite good. Diversity is good but it's also harmful to discussion.

How do I explain to coworkers what MV-Something is about with all of this noise? MVC has acquired buzzword quality.

</rant>

Saturday, July 28, 2007

Water...

Insufficiency of a resource sucks leads to disaster. The pump that draws water from the well to feed the sprinklers in my yard broke down while we were on vacation. Several plants died as a result. As the landlady has not yet replaced the pump, I have also spent quite a few hours watering as best I can in the evening. The mains water pressure is insufficient to be very efficient and I have to move the sprinklers a dozen times each to get reasonable coverage.

Surplus of a resource rocks leads to waste. I can think of few things more gratifying than sitting in a tub full of warm water with my laptop (on a dinner tray) while I work on MbUnit and surf the internet. Sure, the humidity is probably not great for the machine... but I don't intend to keep it for more than 2 or 3 years.

Interesting contrast, no?

Sunday, July 22, 2007

RAD Fad

I'm so tired of Rapid Application Development. It feeds on the natural desire for instant gratification. With some Wizard, I'm sure I can rapidly build a WebForm over some Db table using only a DataGrid some SQL and a few data binding expressions. Ala-kazam!

Ahhh... but what happens next week when I need to twist the DataGrid in ways it won't bend. Uh oh. The magic unravels and is revealed for what it is: mundane lack-luster designer-laden crufty syntax patching over a hard problem with rickety abstractions. Thankfully I know how to solve these problems myself without using wizards.

I find it rather disconcerting that some people cite RAD as the means for transforming their mediocre workforce into a development powerhouse. Well, RAD isn't the only offender here at least. Many other programming practices and technologies have likewise been hailed as counter-examples to Fred Brook's No Silver Bullet. I've yet to see one actually make a sustainable order-of-magnitude leap in productivity however. Instead it appears that actual productivity significantly lags the capacity of available tools and major improvements only occur as each generation of programmers finally succeeds the last.

I think RAD is highly overrated except for demonstrations, mock-ups, and throwaway prototypes (but how often are they really thrown away?). Simply put, RAD optimizes the wrong tasks. The typing is easy so reducing lines of code to opaque graphical squiggles and a multitude of unenlightening property panes is stupid. The programming problems solved by RAD are not especially difficult on their own. The initial development costs are greatly outweighed by subsequent maintenance activities for which RAD tools provide little assistance and may even actively hinder. The mental model proposed by most RAD tools is often not just oversimplified, it is frequently false and misleading: the real system doesn't behave the way the tool made it seem.

In short, I don't believe RAD is a substitute for good training. Why is it so many companies seem to be more eager to purchase shiny new tools than to send their programmers to school? Heck, most RAD tools themselves require a good deal of training to learn to use effectively...

Looking For a Mentor...

Today, I am an excellent Programmer and a very good Software Engineer. I have many years of experience in diverse fields. I am passionate about technology. I enjoy analyzing systems holistically and clearly explaining how they are built-up and torn-down. I am well-respected by my colleagues and friends.

Today, I want three things:

  • I want to refine my skills in System Architecture. I want to write better documentation, produce more accurate estimates, communicate more effectively with more people of diverse backgrounds, and improve my project management abilities.
  • I want to start a company.
  • I want to meet more people who are good at these things, exchange ideas, learn, and have fun...
  • Cube Farms and Segregation Do Not Mix!

    For the past few months, I've been examining my production values. Here's something I wrote earlier today...

    Walls are barriers erected to provide isolation from one's neighbours. When a group is divided by walls, or physically separated by function or class (perhaps to afford senior staff with more window area), rigid constraints are imposed upon allowable communication patterns within the group.

    A properly functioning team can be gathered around quite closely with little or no need at all for walls. Limited privacy and sound isolation are occasionally beneficial but the members of the group should still be proximate to one another physically or virtually. A good team thrives on an effective and productive ambient flow of communication.

    When members of a team strongly wish to isolate themselves from the group, it is a clear sign that these members have abandoned any efforts to improve communication within the team.

    A thoroughly isolated team is no longer a team.

    I've not talked about where I work much because a few of my coworkers read this blog. In any case, these comments should not be construed as representing anything other than my own personal opinions.

    I live in a cube farm. I very seldom interact productively with any of the people nearest my cube, though they are nice people. The people with whom I have the most engaging and valuable discussions are located a hundred feet down the hall. This is in marked contrast with the tight-knit teams to which I belonged at other workplaces. I fondly remember hallway usability testing, group brainstorming, weekly planning sessions, hashing out problems at the pub, and the whoops of joy (or frustration) from down the hall. I miss engaging team communication and effective collaboration.

    I live in a cube farm, and I miss people! How ridiculously broken is that?!