Tuesday, April 04, 2006
The Bungalow
A house with one story and divisions to create rooms is called a Bungalow. When you hear the term Bungalow, you get the idea that it's a house with one story. Here is a listing of the many definitions for a Bungalow.
There are a lot of solutions where a single self-contained application can do the trick. There are also a lot of solutions where there may be other available applications, but unfortunately a lot of the software written in the 90's were meant to stand alone and are meant to be self-contained. They didn't require a lot of other things to operate, and don't really care whether there are any other applications installed in the computer.
Bungalows have a property which can aptly be seen in a lot of these tools: they are small. Back in the early days of personal (and enterprise) computer systems everybody had limited resources -- so the applications needed to be small and self contained. Usually, these applications only do small simple things -- and usually don't require a lot of other applications to perform its duty/purpose.
A Bungalow also has all the rooms in one floor -- so you have only one layer. You have everything you need in one floor, so you don't need to go too far to get something. This is true for self-contained applications where all the functions they need are mostly found in a single binary file (sometimes some services are supplied by external sources like the operating system, or a software library -- think utilities like water, sewer systems, gas pipes, etc.)
So what's wrong with a Bungalow?
It doesn't scale with the people using it. You can only house so much people comfortably in one bungalow. And usually, as the bungalow grows, it's harder to maintain. Not to mention that you can't really grow a bungalow too much, because you're limited by the real estate.
In the same light, standalone applications are like Bungalows, in that they don't scale too well, and as they grow larger they get harder and harder to maintain. Monolithic solutions where all the units of functionality are confined in one application are limited by the computer resources on which the single application is running in.
When does a Bungalow make sense?
A Bungalow makes sense for a low budget small family. They do the job of housing the people, and usually come at a considerably cheaper price tag compared to other house types. It's easy to build, and can last a long time (when built right).
Much like monolithic applications, a low budget firm who doesn't need a scalable solution for a particular problem is a very attractive solution. Keeping things small and simple (and cheap) is just right, especially if they don't expect the requirements to change too much (or even at all, how rarely the case may be). Monolithic software is also easy to build, and can last a long time when built right.
So What's the Point?
When you need a quick solution to a small not so recurring problem (like finding out the square root of a number), you can use small effective tools that come cheap and are functional (like a calculator). However, when you start needing the roots of a transcendental exponential polar system of non-linear equations in N dimensions, then you might not be able to solve that so easily with a simple calculator -- especially if you do it more than once, and need to do it quickly many number of times.
The trick here is recognizing the problem, and the scale of which you're going to be solving these problems. Simple problems usually need simple solutions. If you find a complex problem and see a simple solution, then you're in luck -- otherwise, prepare to come up with a complex solution nonetheless.
Complexity defines size.
There are a lot of solutions where a single self-contained application can do the trick. There are also a lot of solutions where there may be other available applications, but unfortunately a lot of the software written in the 90's were meant to stand alone and are meant to be self-contained. They didn't require a lot of other things to operate, and don't really care whether there are any other applications installed in the computer.
Bungalows have a property which can aptly be seen in a lot of these tools: they are small. Back in the early days of personal (and enterprise) computer systems everybody had limited resources -- so the applications needed to be small and self contained. Usually, these applications only do small simple things -- and usually don't require a lot of other applications to perform its duty/purpose.
A Bungalow also has all the rooms in one floor -- so you have only one layer. You have everything you need in one floor, so you don't need to go too far to get something. This is true for self-contained applications where all the functions they need are mostly found in a single binary file (sometimes some services are supplied by external sources like the operating system, or a software library -- think utilities like water, sewer systems, gas pipes, etc.)
So what's wrong with a Bungalow?
It doesn't scale with the people using it. You can only house so much people comfortably in one bungalow. And usually, as the bungalow grows, it's harder to maintain. Not to mention that you can't really grow a bungalow too much, because you're limited by the real estate.
In the same light, standalone applications are like Bungalows, in that they don't scale too well, and as they grow larger they get harder and harder to maintain. Monolithic solutions where all the units of functionality are confined in one application are limited by the computer resources on which the single application is running in.
When does a Bungalow make sense?
A Bungalow makes sense for a low budget small family. They do the job of housing the people, and usually come at a considerably cheaper price tag compared to other house types. It's easy to build, and can last a long time (when built right).
Much like monolithic applications, a low budget firm who doesn't need a scalable solution for a particular problem is a very attractive solution. Keeping things small and simple (and cheap) is just right, especially if they don't expect the requirements to change too much (or even at all, how rarely the case may be). Monolithic software is also easy to build, and can last a long time when built right.
So What's the Point?
When you need a quick solution to a small not so recurring problem (like finding out the square root of a number), you can use small effective tools that come cheap and are functional (like a calculator). However, when you start needing the roots of a transcendental exponential polar system of non-linear equations in N dimensions, then you might not be able to solve that so easily with a simple calculator -- especially if you do it more than once, and need to do it quickly many number of times.
The trick here is recognizing the problem, and the scale of which you're going to be solving these problems. Simple problems usually need simple solutions. If you find a complex problem and see a simple solution, then you're in luck -- otherwise, prepare to come up with a complex solution nonetheless.
Complexity defines size.
