Frameworks make software easier, but only the easy part

Wednesday 30 August 2006

There’s a lot of talk these days about new web frameworks. Django, Turbogears and Ruby on Rails are leading the charge on new ways to build web applications. They undoubtably save time, improve productivity, and make developers happier. It’s easier to build sites with these frameworks and in these languages than with competing technologies.

Of course, all of the interest and hype will result in some backlash. Hacknot has an amusing rant, All Aboard the Gravy Train (with a great pun, “Now departing platform one”). He ultimately dismisses the new frameworks with:

Your time and energy is better invested in improving your abilities and skills than in adding another notch to your technology belt.

This is throwing out the baby with the bath water, as Pete Lyons ably argues in Defending Ruby on Rails:

The problem with these assertions are that they assume that learning the new technology neither offers new insight into the ‘principles or techniques of software development’ nor would ‘improve your ability and skill’.

I’ve been working in Django for eight months now, and it really is faster and better than other ways we could have chosen to build Tabblo. Django and Python have made the job easier, but only the actual writing of the software, which in my mind, is the easy part to begin with.

Building a great product involves a lot of hard work, much of which has nothing to do with coding:

  • What should the product do?
  • Who are the customers? What do they care about?
  • Of our two (three?, n?) conflicting goals, which should I work on today?
  • How do we architect the software to anticipate the unseen future?
  • What’s the right architecture to ensure the application performs well?
  • What can we do to make sure the site stays running around the clock?
  • How do we balance short-term vs. long-term needs?
  • Which add-on libraries and tools are right to incorporate into the product?
  • How do we assess the quality of the product?
  • What’s the right balance between adding features and fixing bugs?
  • Which are the bugs that really interfere with the product’s success?
  • When is the software “done enough”?
  • How do we gauge the risk of any decision we make? How do we mitigate it? What’s plan B?
  • What are the lessons from previous projects that apply here? Is this history repeating itself, or are we in new territory?

And this isn’t even covering the larger organizational issues of management, team building, and general inter-personal stuff that any software engineer on a real product will have to deal with, not to mention whole-business concerns like marketing, sales, support, and so on.

When I worked at Digital in the printer group, there was a joke among the software engineers: we claimed the hardware guys looked down on us because they thought that writing software was “just typing”. By focusing purely on coding issues, we software engineers run the risk of taking the same stupid view of our world.

At a certain simplisitic level, a web app is a straightforward piece of software: it has to accept request at URLs, dive into a database to get some data, build some results, format them into HTML, and return them to the browser. Django and Rails make this process easier, absolutely. But building a great web application involves so much more difficult work. The frameworks can help by simplifying coding so that we can focus on the remaining difficult problems.

When the hype-masters claim that their frameworks and languages make coding an application easier, they are absolutely right. But that’s already the easy part.


While I'm completely with you wrt the business and people issues being a larger challenge to the overall success of a project than the actual software development, I'm not sure that any of us have been claiming to be tackling those issues.

While this: "At a certain simplisitic level, a web app is a straightforward piece of software: it has to accept request at URLs, dive into a database to get some data, build some results, format them into HTML, and return them to the browser." may be true, the devil's in the details and it's still a non-trivial effort to develop a solid webapp, particularly when you don't have a framework removing a bunch of the common details for you.

While the words used in your article are accurate, the overall tone and message seems to be "who cares about web frameworks, because they just take on stuff that's easy?" But that overall message contradicts this: "The frameworks can help by simplifying coding so that we can focus on the remaining difficult problems." That, it seems to me, is *exactly* the point. The difference between a Java webapp and a TurboGears app is pretty striking, and shrinking the time spent in actually building the software is a big plus because it leaves more space for people in the business to focus on the bigger issues and less on the mundane.

So, sure, TG, RoR and Django don't *directly* tackle the big issues, but getting out of the way so that people can tackle those issues certainly seems like a good step to me.
Kevin, thanks for chiming in. I certainly didn't mean to imply that the frameworks are good for nothing. I was reacting to an overall zeitgeist in the air along the lines of, "These days, it's easy to make a web 2.0 app: just open up a can of Ruby on Rails!"

I wouldn't consider doing a web app any other way at this point. It really is much easier. I just wanted to remind people of all the other concerns that affect the success of a product.

The true framework technologists are not claiming the frameworks solve these other problems. But the hyperventilating enthusiasts I think are maybe in a different boat.
Well said, Ned!

I've joked a few times that Django actually makes my job *harder* because instead of spending time writing easy stuff like SQL I have to skep directly to the hard things you talked about.
Your title says it all, I think. Languages like Ruby are elegant, and Rails (though I haven't used it much) seems like a useful tool. However, I find that what's usually holding back my "productivity" is the lack of round-tuits — even in modern programming paradigms.
Andrew Magerman 10:34 AM on 1 Sep 2006
Hi Ned,

This post was a real breath of fresh air. I completely agree that the success of a project has more to do with soft factors than the platform or the technology. (At least I think that is the point you are saying).

One point I would also mention is also managing client expectation. In the past I was a lot greener, and a lot more technically oriented. The customer would say "We would like A, B and C" and I would happily implement everything even though I knew this would create problems later.

Man, what a mistake. Nowadays I am a lot more cautious and generally say things like "Well, it would be possible but not recommended because...."

I think also that another point is valid: that people generally do not differentiate between a tool and a process. Either here in this case : "We have a great tool, our development process will be improved (not necessarily as you pointed out)" but also when customers come with beliefs that they will change the people work just by giving them access to a database. The complicated bit is getting people to change their habits, not actually producing the tool.
Good post!

Requirements engineering and project management are the main reasons for failing projects. So it is not about technical stuff. The frameworks help with the technical part but do not guarantee a successful project.

Best regards,
Ronny De Winter

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.