Most of my clients, when discussing software development, they justify themselves by telling me that they don’t understand much about it. I always respond that, in order for their software development projects to be successful, they have to understand some basic concepts at least. However, they’re usually not very motivated to learn about software development. “Not my piece of cake”, “I just want to use the software, not understand it”, “Too complicated for me”, or even “It doesn’t interest me”.
Yet, I try to obtain their interest anyway. If you want to have your own software built (like many of my clients), I’m very sorry, but you just have to understand some things about it. One of the strategies I use in my communication, is to compare software development to something people do know about. For instance, development of software can be compared to building a car. In this article I will use another analogy, by comparing software development to the construction of a house.
Here are four similarities. Useful for anyone that struggles in communicating with software builders or software sellers. Interesting for everyone else!
Think twice before you build your own house
Let’s start with an observation. Most people don’t build their own house (or have it built). They buy a house that’s already out there. Sometimes it’s brand new, most of the times it’s been used before. Why? Because these houses are just there: they’ve proven themselves to be useful houses. Why bother building a house from scratch if you can find an existing one that fits your needs and desires? Building a house is difficult, even if you don’t build it yourself, you’ll need to know at least something about architecture and construction.
The same thing applies to software: use existing and proven software if you can, and if not, have your own software built only in case:
- you have very specific wishes
- you know at least the basics of software development yourself
- you have a very good budget to spend
Design is everything
Let’s say you do want to have your own house be constructed, and you can’t do it yourself. How do you start? Well, you need a design, right? A good design! Therefore you hire an architect who will do basically two things:
- make a design that reflects how you would like the house to look like: exterior, rooms, floors, materials etc.
- make a design that proves how the house should be built: what are the important walls, what are the exact dimensions, what parts are reinforced, what quality of materials is to be used, etc.
The first one can be called a functional design, and this is where you, the client, should (and probably wants to!) play an active role. The second one is the technical design. As a client that does not know much about construction, you’ll probably not interfere much. Good practice however would be to have the technical design be made by an independent architect, i.e. not someone that is involved in the construction itself. Why? Let’s assume you have the construction worker make the technical design (so not an independent architect). He’ll probably does it in such way that it serves his own interest: maybe he’ll implement very expensive materials you don’t really need (but he’ll make good money out of it) or he leaves out security components he thinks are too much work to implement.
Now back to software development: it works exactly the same! You need a functional and a technical design. And you want the designer to be somebody else than the software developer, if your aim is to have long lasting and price-quality balanced software. Needless to mention: bad design = bad house.
Building is composing
As the preceding paragraph pointed out, a good house is built according to a good plan. However, it is not necessary to completely construct it from scratch. For a great part, the constructor uses components and puts them together. The design leaves a hole in the wall, a window (=component) is put in there. In case the window ever needs to be replaced, it can be easily done so. This is characteristic of components: they’re rather independent parts of a construction. The constructor’s effort is this: integrate the component in the bigger whole.
Good software is built, and characterized, in the same way. If possible, and preferably, existing components are used (the implementation requires some effort) within a certain architecture. Only in case no useful component exists for a certain feature or requirement, it is good practice to create a new component.
Example: say your software application needs to be able to exchange information with your bank. A component is implemented (existing or newly created), that does just this. In case you move to another bank, only this component needs to be replaced (or adjusted), the rest of the architecture will not need any adjustments.
You’ll need maintenance
A house needs maintenance, not much explanation necessary here. You’ll need to paint wooden parts once in a while, especially the ones exposed to wind and weather. A roof does not have eternal life for the same reason.
Of course, software is not exposed to wind and weather, still, it needs maintenance. Basically this is because software is almost never standalone or independent. It always depends on hardware (a PC, smart phone or server) and other software (a software system that operates the hardware that is used: the operating system, like Windows or Linux). These two, hardware and operating system tend to come with new versions every few years, having consequences for all software applications that depend on them. Here’s a longer list of common reasons for maintenance of software:
- hardware or operating system upgrade (just explained)
- security reasons (especially when the software communicates with the world outside, sometimes you just have to make things more secure)
- bugs: unfortunately software is, and will never be, failure free
One last observation: when you notice that your house needs an extraordinary amount of maintenance, something more fundamental is wrong. Most probably there’s a serious construction error (usage of some inadequate components if you’re lucky, fairly easy to replace), or much worse, the house has been built according to an inadequate architecture, which is very difficult, if not impossible to fix. Needless to say, the exact same thing applies to software!