A long hiatus again, almost forgot I even had this blog. The more experienced I become in the world of IT, the less interested I seem to be of the latest and greatest stuff. Of course I keep my eye on the new tools and technologies, but increasingly I find myself looking in the past of IT, to the age when thinking wasn't still polluted with all the things we take as given now.
I've watched Doug Engelbart's Mother Of All Demos recently and if you disregard the bad picture quality, it's simply mind-blowing what he and his team were able to come up with in 1968! That's 43 years ago and we're still not quite there yet.
In my understanding one of the main ideas of his research back then was to augment human thinking with the help of computers. The route to this, in his view, was mainly achieved by good real-time collaboration tools like audio/video-conferencing and real time collaborative document editing among other things.
We've had wikis for some years now, but let's be honest: most of them aren't that great at real time collaboration. Then we have a plethora of different kinds of messengers and Skype of course. And then different sketching tools for managing complex abstractions (like software design). But none of these provide a unified experience.
The closest we've gotten so far was with the failed Google Wave. We still weren't ready for it I guess, but I'm willing to do a small bet that the idea will resurface somewhere in some form. Back when I first saw Wave, my first thought was "wouldn't it be awesome to have a programming environment based on that idea". Maybe something like the apparently dead Code Bubbles project combined with Wave's real time collaboration.
Sadly we're not only restricted by missing technology. A big obstacle in the ways of efficient computer-aided collaboration is company policies and general reluctance to collaborate online. There are exceptions, like the previous company I worked for, Ambientia. While working for them I had possibly the most advanced online collaboration experience so far.
First a bit about their company culture. They're a mid-sized IT-shop, but scattered into multiple small offices. Also their headquarters are "off-site" to most customers which seems to promote more liberal thinking regarding physical presence in the lines of: "Oh, our customers are 100km away anyway so how can we demand that all employers sit in the same office all day". Instead they've become completely transparent to physical location. Every employee is in Skype and roughly 90% of their internal communication happens in project- or topic-specific persistent chats or ad-hoc audio meetings in Skype. The amount of email was minimal.
Anyway, I had the task of designing a UI for a small software with the help of a user interface specialist. Here's how it happened: We went to the project's Skype chat and agreed that we'll need to do something and we can do it now. That turned into a Skype audio chat (video is totally unnecessary for most things) and after a brief discussion we decided to do the design in real time collaboration. We had Confluence wiki with Balsamiq-plugin installed and we agreed that he would be the one doing the drawing. He shared his screen in Skype so I could see in real time what he was drawing and when we had an intermediate version, I could go check it in Confluence right away and add my modifications.
The point to take from this story is that in my experience our one hour online collaboration session was more productive than if we had been sitting face to face. Why? No need to reserve meeting rooms or time, because of location transparency all of it can be done ad-hoc. Another reason is that this toolset made us focus more on the actual task. And most importantly, all this was much less intrusive then a full blown meeting. He could attend another meeting in another city that day and I could stay home with my kid who was sick.
As much good as agile movement has done for the software development world, in this regard its taken steps back. Nowadays it seems to be the norm that we set up a scrum team and force them to sit in the same room 8 hours a day and forget all about any kind of online collaboration.
Here's an idea for the employers out there: use agile, but sacrifice a bit of the efficiency and give your employees freedom regarding location. This way some very talented people, who otherwise might not be interested in working for your company, might take the offer. And you get to extend your hiring anywhere in the world, time zones considered.
Saturday, June 11, 2011
Saturday, February 5, 2011
Tools versus frameworks
Sorry about the hiatus. I've been busy setting up my own company and it's running now. Today's topic is a difficult one: I'll try to describe the problems of frameworks in software production and how I think a "tool" is often a better way to raise productivity and quality.
What is a framework in general? In construction I'd imagine it to be something akin to a mold, something that sets many of the properties and dimensions before we even start the work. As long as you know these properties and dimensions, you're safe and you can apply the framework to save time and increase quality. I'd say the same semantics apply for software frameworks. They set some properties and dimensions of the software artifact when you decide to use the framework in question.
As long as a framework is relatively small with few properties and dimensions, I see no problem. You'll soon memorize the properties and can easily judge if using the framework is a good idea or not. But even initially small and simple frameworks tend to grow more and more complex either from the pressure of the userbase (OSS) or from the pressure to resell the same thing for the tenth time to the same customers (commercial products). Spring is an excellent OSS-world example of this. At it's very first versions, I thought it was brilliant and simple - more like a tool than a framework really. When I look at Spring now, it feels like holding James Joyce's Ulysses in my hands. And Spring isn't even worst of the frameworks, it's actually pretty good.
There are frameworks for everything these days. The useful ones are usually ones that simplify some technical aspect of software engineering, like UI-frameworks or frameworks for transactional components or frameworks for persisting data. The ones that cause usually more problems than they solve are the ones that try to venture in the non-technical problem space of software engineering. So you're planning to create a system for handling resources in your company? Not to worry! There's a plethora of amazing ERP-frameworks that only need a tad of configuration and you're done! Not.
The illusion here is that while many problems in software engineering resemble each other a lot, like ERP or CRM or information publishing (CMS), I've rarely seen a company actually adapt to the properties and dimensions the framework they're building things on. The thing most CTO's are missing is that if you choose to use a generic framework for CRM, you'll have to be prepared to modify the organization and processes of the company to adhere to the rules of the framework.
From the programmers perspective, frameworks generally suck. In the time it takes to understand all the rules and dimensions of the framework, a good programmer with good tools is usually done with the original requirement. And what happens when the requirement doesn't neatly fit in any of the available properties of the framework? Cludges, hacks, hours and days spent trying to circumvent the bloody thing.
Ok, enough raving about how frameworks suck. Tools - those I like. Why?
Let's consider a hammer, one of my favorite concrete tools. It's small, very simple and doesn't take long to understand how it works. You grab the other end and hit something with the round end or use the other end to pull off nails. But there's more. Once you learn the simple properties of the hammer well (after all, there aren't that many of them), you'll start to use it in more novel ways. For hitting other tools, for breaking concrete, adjusting a heavy shaft, heck you can even use it to forge steel.
A software tool is something similar to a hammer for me. It has one clearly defined purpose of use, for example to create XML-based REST-services with plain old java without external configurations. How does a tool differ from a framework here, you must be asking. A tool doesn't force you to any particular style of REST-services; a tool doesn't abstract away the Servlet API nor HTTP-protocol; a tool doesn't force you to change your architecture if you decide to use it; a tool lets you adapt it easily to better fit your need. A framework doesn't have these qualities.
I seem to be developing an undercurrent running through all my blog posts. Here it is again: It takes an experienced and courageous architect to decide against using massive frameworks. Sure, there are architectures that are a perfect fit for framework X, but only after coming up with the architecture without using a framework as a crutch. A good architect always first starts with a clean table, trying to imagine the simplest possible solution that would fulfill only the known requirements and nothing more. It's easy to add more complexity to that, but extremely hard to remove unneeded complexity afterwards.
The lesson here, if there is such, is to be prepared to sometimes take a few steps back in your work and try to think as the great minds in our field did 30 or 40 years ago. Sometimes it's the correct solution to create a tool for the task you're doing. Think of the Unix-philosophy where there are dozens of small clearly defined command line tools. They're still used and useful and, although I might not agree, I know people who think there isn't a problem in software engineering that couldn't be best solved by combining a bunch of Unix-tools in a creative way.
What is a framework in general? In construction I'd imagine it to be something akin to a mold, something that sets many of the properties and dimensions before we even start the work. As long as you know these properties and dimensions, you're safe and you can apply the framework to save time and increase quality. I'd say the same semantics apply for software frameworks. They set some properties and dimensions of the software artifact when you decide to use the framework in question.
As long as a framework is relatively small with few properties and dimensions, I see no problem. You'll soon memorize the properties and can easily judge if using the framework is a good idea or not. But even initially small and simple frameworks tend to grow more and more complex either from the pressure of the userbase (OSS) or from the pressure to resell the same thing for the tenth time to the same customers (commercial products). Spring is an excellent OSS-world example of this. At it's very first versions, I thought it was brilliant and simple - more like a tool than a framework really. When I look at Spring now, it feels like holding James Joyce's Ulysses in my hands. And Spring isn't even worst of the frameworks, it's actually pretty good.
There are frameworks for everything these days. The useful ones are usually ones that simplify some technical aspect of software engineering, like UI-frameworks or frameworks for transactional components or frameworks for persisting data. The ones that cause usually more problems than they solve are the ones that try to venture in the non-technical problem space of software engineering. So you're planning to create a system for handling resources in your company? Not to worry! There's a plethora of amazing ERP-frameworks that only need a tad of configuration and you're done! Not.
The illusion here is that while many problems in software engineering resemble each other a lot, like ERP or CRM or information publishing (CMS), I've rarely seen a company actually adapt to the properties and dimensions the framework they're building things on. The thing most CTO's are missing is that if you choose to use a generic framework for CRM, you'll have to be prepared to modify the organization and processes of the company to adhere to the rules of the framework.
From the programmers perspective, frameworks generally suck. In the time it takes to understand all the rules and dimensions of the framework, a good programmer with good tools is usually done with the original requirement. And what happens when the requirement doesn't neatly fit in any of the available properties of the framework? Cludges, hacks, hours and days spent trying to circumvent the bloody thing.
Ok, enough raving about how frameworks suck. Tools - those I like. Why?
Let's consider a hammer, one of my favorite concrete tools. It's small, very simple and doesn't take long to understand how it works. You grab the other end and hit something with the round end or use the other end to pull off nails. But there's more. Once you learn the simple properties of the hammer well (after all, there aren't that many of them), you'll start to use it in more novel ways. For hitting other tools, for breaking concrete, adjusting a heavy shaft, heck you can even use it to forge steel.
A software tool is something similar to a hammer for me. It has one clearly defined purpose of use, for example to create XML-based REST-services with plain old java without external configurations. How does a tool differ from a framework here, you must be asking. A tool doesn't force you to any particular style of REST-services; a tool doesn't abstract away the Servlet API nor HTTP-protocol; a tool doesn't force you to change your architecture if you decide to use it; a tool lets you adapt it easily to better fit your need. A framework doesn't have these qualities.
I seem to be developing an undercurrent running through all my blog posts. Here it is again: It takes an experienced and courageous architect to decide against using massive frameworks. Sure, there are architectures that are a perfect fit for framework X, but only after coming up with the architecture without using a framework as a crutch. A good architect always first starts with a clean table, trying to imagine the simplest possible solution that would fulfill only the known requirements and nothing more. It's easy to add more complexity to that, but extremely hard to remove unneeded complexity afterwards.
The lesson here, if there is such, is to be prepared to sometimes take a few steps back in your work and try to think as the great minds in our field did 30 or 40 years ago. Sometimes it's the correct solution to create a tool for the task you're doing. Think of the Unix-philosophy where there are dozens of small clearly defined command line tools. They're still used and useful and, although I might not agree, I know people who think there isn't a problem in software engineering that couldn't be best solved by combining a bunch of Unix-tools in a creative way.
Subscribe to:
Posts (Atom)