Divide et impera

We’re not at History, but I just want to make use of this to express in a funny way how can you came up with a really powerful product design.

I’m going to talk about software, because this is what I do most, but this apply to any kind of product or service development.

One of the main problem in software is that the design behind a product, usually is not so good. We tend to think that if we rush to do something because our mind think faster then we write, it’s better then just sit quite for a while and think.

This is very well expressed in the woodpecker joke:

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. (Gerald Weinberg)

So why do you need a good design? 2 main reasons:

  1. Reusability. You don’t want to write or copy/paste the same stuff again and again.
  2. You always need a scaled design.

Scalability has 2 sides:

  1. It’s the ability to easily change the product so you can keep up with the changes in the specifications. And the specs … they always change. The initial specs won’t last to long. That’s proven.
  2. It’s the capacity of a system to handle more load, i.e. growth in the amount of users or processes it needs to handle.

Just handle first side and the second will be handled by itself with only some extra resources and maybe a bit more work. The product design is the critical aspect for a good, long term development process.

So how do you know your design is a good one? In the end we based our development on a design, good or bad, but it’s a design.

OK, most likely it’s not going to be perfect from the first time, but the more you choose the right approach, the easier will be next time and so on. And even if you start with a design that’s not so good, and you figure out in time the mistakes, trust me, you’ll end up fixing it without starting it over from the scratch. And refactoring will be like a bad dream, because now you’re in the real world.

There it one rule only (which we can divide it into sub rules, but maybe later :)), and it always work. The title :). Yes, the title! Divide et impera. It sound hilarious, but I like how it sound. It’s not really like we’re conquering anything, but we do have lots of benefits. From what? From dividing. And what’s even more funny then what I expected to be, is that this quote is around for more then 2000 years. Look for it!

Yes, this is the basic of an almost perfect design. That’s because there’s nothing perfect in this world. And we need to cope as much as possible with it.

So let’s get into a bit of details. You have a problem, which is more or less complex. Go ahead and divide it into subproblems, then the subproblems into more subproblems, and these ones as well, and so on. What you’ll end up with is a set of modules, very simple modules. Take those modules and implement them separately, and try to think at the right way to do it, taking into account any other context where you might use that particular module. You’ll end up with the first gain of doing so: reusability.

For instance, you need a circle in your calculations. Make an Ellipse class, then extend it to a Circle. You put all the properties inside and then you’re good to go. Anywhere you’ll need a circle or ellipse, you don’t need to rethink the whole stuff again. Don’t keep it with 2 members where you need it, like center and radius, or x, y, r, which are actually 3. Just use a Circle object.

Let’s say in your app you want to create an UI. Don’t do it only for the context you’re in. Maybe you’ll need to show that in another context later. You don’t have to do it twice and to copy/paste buckets of code form a place to another. Write it only once in a way so you can use it in several places.

Do not make cross references. This is a really poor approach. It will force your module to depend on to many external things, while you need it free. Use delegates or listeners instead.

Then take the modules and link them. Method calls, references, delegates, maybe some algorithms, you name it. The link it’s just an abstract bridge between the modules. A way to communicate or to keep them tie. Like a wire or a screw.

Doing this you have all the chances to end up with a great design for your app or product or whatever project you might have. You’ll have reusable components, the project will be flexible, scalable, modular, just like that, and you’ll be really happy, and really amassed that this actually works. And even the woodpecker won’t be able to crack it 😉