Ming the Mechanic
The NewsLog of Flemming Funch

Sunday, November 5, 2006day link 

 Night lights
picture
This is a NASA picture from here of sunset over Europe and Africa. Digitally composited.

Which I'm thinking of because there was a power failure here last night, which affected big chunks of Europe. It was only 45 minutes or so here in Toulouse, but long enough to start a fire in the fireplace, have cocoa, and spend a cozy time while the computers and the TVs were off.
[ | 2006-11-05 19:56 | 3 comments | PermaLink ]  More >

 Simplicity and embracing constraints
Jon Udell mentions Dabble DB:
The October episode of The Screening Room features Dabble DB, a web-based workgroup database that, in the style of 37Signals, focuses on simplicity and embraces constraints. Dabble doesn't aim to do full-blown database application development, or sophisticated query, or heavy transactions. Its mission, instead, is to enable teams to easily manage and flexibly evolve modest (say, 30- to 50-megabyte) quantities of structured data.
Now, Dabble is first of all cool, but that brings up several things. Dabble is a database you create on the fly online, which you very easily can import stuff into, particularly from spreadsheets, and you can very easily change it around, add fields, etc. And it is often intelligent enough to figure out what you might want to do, and making it easy.

That reminds me first that I made a program like that several years ago, where you create a database online, and you can change it on the fly, and import stuff into it, and you automatically have screens for searching, sorting, updating it, etc, and you don't need to know much about databases. My web app isn't nearly as cool, doesn't do any Ajax tricks, and doesn't make it nearly as easy. There are people using my app, who're happy with it, but I never got it to a point where it would be meaningful to market it.

That's a bit of a puzzle I have as a programmer. Should I make a bunch of different functionalities that are tied together, but spread myself so thin that it ends up being a bit mediocre and not quite finished? Or should I get a team together and do it better? Or, should I do what is the current Web2.0 fashion - do one rather simple, limited thing, but make it very cool and easy to use, and then charge people per month for using it.

As he says, focus on simplicity and embrace constraints. Make it very simple, refuse the temptation to add more advanced features. Make the simplicity and lack of features BE a feature.

Like 37 Signals, obviously. Very smart people making very simple programs, even bragging about how quickly they made them, but making them so well that they're very intuitive to use, and so compelling that thousands will happily spend $10 per month for using one of them.

I'm trying to talk myself into it... Intellectually I get it, but instinctively I'd tend to go for a too-complicated solution, when a more simple would do.

My pet programming project the last couple of years has been a collaborative environment I call OrgSpace, which has wikis, blogs, calendars, forums, chat rooms, project management, contact lists, event management, databases, a shopping cart, workgroups, and more, all integrated with each other. But that makes it so damned complicated that it is a bit crazy to try to do single-handedly.

And some of the things I've done successfully have been very simple. Like the webcam thing I did in Opentopia. Took me not much more than a weekend to do, but it has gotten more hits than anything else I've put on the web. I recently sold that website, and it all sort of speaks for the idea of doing simple and cool things and getting them out the door.

So, I'm trying to meditate on that simplicity-and-embracing-constraints message.

It is like The Mythical Man-Month. Complexity grows exponentially as, uhm, things get more complex. When a software project grows so complicated that one person can't easily understand all of it at one time, the need for communication between team members makes it quickly mushroom way out of proportion. A small team of 3-5 people can be very productive, but anything beyond that starts getting crazy. For that matter, even if it is a one-person project, if he can't easily comprehend the total project at the same time, it gets too complex as well.

Scaling it up much further, how about understanding and solving humankind's problems? Does some committee need to somehow solve the big problems together, even though they have a hard time understanding the full system? Or is it maybe better if small groups of people solve very specific and limited problems, but they solve them so well that their piece becomes a fine building block for bigger solutions, which they maybe can't even imagine.

I could say that this is maybe nature's way of dealing with complexity. A whale is very good at being a whale and plankton is very good at being plankton, but none of them lose any sleep over pondering the complexities of the ecosystem. And yet they're integral parts of it. If they made a big committee, they probably wouldn't do as good a job at it.

It could be a human type of hubris that we think it is our job to come up with big general solutions for complex problems we don't really understand. Rather than coming up with elegant and complete solutions to small problems that we do understand. I'm not sure. Just a philosophical thought.
[ | 2006-11-05 20:36 | 3 comments | PermaLink ]  More >

Main Page: ming.tv