Definition of Good Software Developers and Software Architects

Alex has a very interesting post up, What the good developer and the good software architect really are.

His definition (explained at length in the post):
A “Skilled computer user is a person who can accomplish most of their goals using computer and software installed on it by himself“.

A “Software Developer is a person who can make another person be able to accomplish their goals using new software they made“.

A “Software Architect is a person who can make another person be able to accomplish their goal as a Software Developer“.

I think this is a helpful definition, both in our roles as software developers (to try and be clear about what we want our users to be able to accomplish, and to view their failures in using our software as calls to our own improvement) but especially as software architects (we need to have clear goals, as architects, about what kind of capabilities we want our software developers to have, and to measure our success by theirs).

A Secret: Passion and Your Choice of Web Framework

I will tell you a secret. I am passionate about Smalltalk and the Seaside web app framework. Not just on an intellectual level, “oh hey this is pretty cool, it’s got some good ideas”. But on a fire-in-my-heart level, “this is profound and important technology” kind of stuff.

Why? Good god, why? Why should a choice of language, or especially a choice of which web app framework to use, matter? Because, I believe that:

Your choice of app framework deeply affects your development speed, and your overall level of courage.

Choosing the right framework means you will finish your projects faster, and you will dare to include better and more audacious features in it.

Life is very short. You have a limited amount of time in which to realize your dreams, in which to do your projects. If you’re like me, you probably have dozens and dozens of ideas for apps, sites, portals, that you want to implement. Most of those ideas will suck. But you don’t know which ones, you won’t know until you try them. Your goal, in this life, is to iterate faster. To fail more, to fail quicker, until you get to the brilliant ideas and brilliant projects that can change the world, or at least make you a dollar or two.

I want to be able to code at the speed of thought. At the speed of dreaming. Or rather, at the speed of essential complexity, without the overhead of the accidental. See, there is a notion in computer science of Essential complexity versus Accidental complexity. Essential complexity is “Hmm, I’m trying to solve a difficult real-world problem that is complex and messy”, and accidental complexity is “why the hell can’t I easily do this simple thing in my framework?!”. And I believe that while the first will never go away, there is still too much of the second, of the overhead, of cruft, in the world of web frameworks.

Based on my experience, I believe that the Seaside framework is the most powerful and flexible one, that has the potential to come closest to “development at the speed of dreaming”. It is not quite there yet. But it can be, with not too much more effort.

Now it’s time for a confession: the fastest-to-develop in, most prototype-friendly framework that I’ve had the pleasure to work with so far is not Seaside, nor is it Ruby on Rails (which has other reasons to recommend it). It’s a relatively unknown (dare I say underdog?) Python framework called web2py, headed by Massimo Di Pierro. Its ease of use, quality of documentation and community support, and the amount (and integration) of out-of-the-box features made (on large project with a small team) development quick, easy and secure. I am seriously grateful to Massimo and the web2py community for raising my standards of what a web app framework should do.

Then what am I doing here? Why isn’t this blog called “web2py Zen”? Because, I believe that the features that make web2py fantastic (like comprehensive documentation, out-of-the-box authentication and user management, ease of use and diversity of persistence options, amazing error logging capabilities, etc) can be added to Seaside – with some effort, but it’s not impossible. Whereas the key features of Seaside (the continuations, the reuse and embedding of components, Halos and the debugging process) cannot be easily (or at all) added to web2py. Smalltalk (and Seaside) is fundamentally “upstream” to Python, in the sense that Paul Graham writes about.

So, Seaside could be my ideal web app framework. It is built on some amazing technology, and has features unsurpassed by any other framework at the moment (and has plenty of drawbacks, sure, but none unfixable). It’s going to take some work (and that’s part of what starting this blog has been about, for me), but it also has a vibrant community around it that I think is up to the task.

One more thing. While I believe that the choice of frameworks is important, and that some are, objectively, better than others (for certain goals), I don’t want the arguments over which one is better to be based solely on personal opinion. I want the frameworks to prove themselves, to pull their own weight. What I really want to see is studies, and competitions between frameworks. I want web framework olympics, of the kind that Plat-Forms is trying to do (only that’s in Germany – I would love to see more US-based ones). I want to see evidence, and experimentation. And will strive to provide some of my own.

Am I advocating that you choose one framework (that you think is best) and really focus on it, practice the hell out of it? Yes. But also: You have to try all the other frameworks. You have to periodically re-evaluate your choice. If some other framework is doing something fundamentally right, and you can easily add it to your framework, do it. If not, if they’re doing something right and profound and you can’t add it to your framework (perhaps because of language limitations), perhaps you need to reconsider your allegiance.

In any case, whatever your favorite language: Choose the right app framework. Love it, improve it, practice the hell out of it. Re-evaluate your choices periodically. And iterate faster.