Code frameworks and ghettos, where creativity gets a lock-in

I once read a rant by an open source developer called Zed Shaw, where he was saying that Rails is a ghetto. Zed was venting frustration about some members of the Rails (of Ruby on Rails) community, apparently he couldn’t monetise his skills properly due to politics in the community. Hence it felt like a ghetto to him. An interesting point I took from his rant was that you could get stuck in a framework and not achieve your goals, easy to guess but also easily overlooked. As I write this post, I checked the rant again for reference and I found that Zed withdrew it and replaced it with a much more toned down text, you can read that here.

A code framework can be a force for good when it solves infrastructural issues and allow developers to concentrate on the specific job at hand. When the job is about addressing a user need, then it is well worth investigating the benefits of any framework before diving in head first. But when the job itself is about infrastructure, then the story could get more complicated. In this post, I am only addressing situations when the job is about addressing user needs.

Many code frameworks are useful for beginners, useful for creating an initial solution framework. That’s the first phase of bringing ideas to life, this is where you’ve realised your Hello World and you’re all pumped up about how easy that was.

A second phase kicks in as you start learning more about the problem domain and potential solutions, you usually iterate through your design and code to reflect changes. This is a good test of the chosen framework’s flexibility, can you improve your design easily? can you improve your code easily? The further in the development, the more acute the questions become. If you’re lucky to think like the framework designers do, then progress should be swift. If not then a tough reality would start to dawn on you. Either way, your creativity start to be shaped by the frameworks that you’re using. This is where the potential pains with frameworks start to surface, it is a good learning stage. I liken this phase to betting on horse race: it always seems that the next bet will be a hit, people keep on betting. Invariably, there will come a time when the developer could feel that he was cheated somehow, he wasn’t told something or that he didn’t realise something.

The third phase in this framework journey is when the coding is done, and the application need to be put into production use. In this phase, performance and reliability issues usually start to pop up. The inevitable questions arise: is there anything wrong in my code? was the infrastructure correctly setup? If you don’t think the way your framework designers want you to think, then you could make missteps and issues would compound quickly. And maybe you do, but you just can’t help much since the framework ties you down. In this stage, only an elite few is able to efficiently address such issues. In the unfortunate case where the troubles call for an audit or project rescue by another party, the business owners tend to feel a bigger pain as their purse is severely tapped because an entirely different way of thinking and seeing the world is brought in.

Code frameworks are like giant bags of assumptions about technology, people, problem and solution domains. They help if the assumptions largely apply in the most significant aspects. When choosing frameworks, do people realise the extent of the assumptions they are about to make? How often do people bother to (or are equipped to) check such assumptions? These are interesting questions for a survey.

Creativity lock-in is not a bad thing if it helps people focus on specific and relevant problem and solution domains. When that is not the case, creativity lock-in can have devastating consequences. Ghetto can be a bit of a hyperbole, but it is a powerful paradigm for reminding people to consider a broader picture when selecting frameworks. A code framework should help with project technical hygiene, open up more opportunities. When the selection is mostly based on product marketing, then the assumptions are not being checked, who’s at fault then? – I wouldn’t blame the product vendors.

One comment

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.