Break It Down

It's coming up on forty years since the publication of D.L. Parnas's classic paper on how to break a problem down into pieces. Slightly later, Glenford Myers wrote about software design and the principles of coupling and cohesion of modules. The whole of computer science teaches us: break a problem down into reusable pieces that communicate solely through well-defined interfaces.

And still the temptation is there, under the pressure of deadlines and demands from customers, to take the easy way out.

If the SL client honored those principles of minimal coupling and strongly cohesive modules, it would be easy to create new user interfaces, or keep an old one as an option. None of the brouhaha over being forced to use the 2.x UI would have happened. Hamlet Au writes about SL and the disabled, and how, ironically, a virtual world that lets one escape one's handicaps to an extent has a UI that can be hard for the disabled to use. One UI will do for the able-bodied, but there are many disabilities. Locking shifts? Sip and puff? Some analog of sonar for the blind, or a force feedback device that can be made to act like a Hoover cane? The potential users for a specialized interface form a small market that will be waiting forever for Linden Lab to create something for them. Make it possible for anyone to create a user interface, and people will.

Of course, we're partly at fault. Darn it,. the problem we've found is the most important in Second Life, and must be fixed now! [Insert favorite threat of what we'll do if it's not fixed this very instant here.] Just piling on more of that motivation to take the short cut, the easy way out... the fix that violates the interface, sneaks a peek at data that should be hidden.

Tateru Nino writes about the issue, and I've seen comments on web sites of third-party viewers about the amount of coupling between the UI and the rest of the client.

Would you be willing to accept some delay in fixing your favorite bug if LL would take the trouble to do it over right?