Simple Is Good:

"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."  - C. A. R. Hoare

"Make everything as simple as possible, but not simpler. "  - Albert Einstein (1879-1955)

"Thank you, Lord, for making all necessary things simple, and all complicated things unnecessary" - H. S. Skovoroda (1722-1794)

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."  - Albert Einstein (1879-1955)

KISS principle - Keep It Simple, Stupid - I don't know the author

"You can see that [with a simpler toolkit] the amount of extension programming goes up considerably. What you don't see is that the total implementation effort may be much lower because the underlying toolkit is much simpler. There the programmers need spend much less time reading documentation, fitting their new software into the old, etc. Sometimes less is more. " - Philip Greenspun, www.arsdigita.com/books/panda/community

I believe you should find simple ways to do things.

Because if you think it takes 2 weeks - it will take 2 months.
Whereas if you think it will take 2 months - it will take a year.
And in the middle you or your boss will realize that it should be done differently - thus you will never finish it.

Many projects failed because their architects failed to make things simple. They tried to make things right. As a result they have built systems which were never quite operational and couldn't survive change.

The great marketer Joe Sugarman has a little formula for judging any project he gets involved in. He calls it -ELF-. That stands for Easy, Fun, and Lucrative.

Often 10% of features takes 90% of your programming time. By sacrificing them you may make your project 10 times simpler.

Same principle can be applied to the features of programming architecture. Trying to make perfect code may make your project 10 times more complex.

Here is a wonderful story illustrating the above: http://philip.greenspun.com/humor/eecs-difference-explained

I truly believe that every time when you have to choose between "making things right" and "making things simple", the simple path will be much better for you over and over again.

That's, for example, how we managed to build a portable myograph in 1989. We were told, that it was not possible to do. But we did it in several months. Because we didn't have a lot of resources and couldn't do things right - but we knew the key requirements, and all other pieces eventually fell into place. Our competitors having literally 100 times more resources (money, people, etc.) - had never finished the project. Because they wanted to make things right. So they drew a plan, distributed responsibilities, debated and agreed on a 5-year budget - and they have never (NEVER) delivered a final product.

You have to decide very carefully whether you really need to deliver a finished application - or the client will be much happier with a framework (set of tools and modules) which allows him to get functionality he needs.

It is ~100 times more difficult to deliver a finished application, because you have to test it on all supported platforms, provide documentation and customer service, work out all small details. On the other side, finished application is not flexible and may not fit customer needs. The bigger the client - the more flexibility he may require.

Thus it makes no sense to spend too much time on making a turn-key application for a big client. Instead you may design a set of modules which allow to easily construct custom applications for the client. Working with many clients you will add more modules to the system making it more valuable to your market.

Each individual module can be small, manageable and reliable. The custom application as a whole will be probably built by the client - so you don't have to provide customer support on it's quality.

Thus by shifting your goal from making a compiled product to making a framework, you made your work 10..100 times simpler and easier - and you made yourself 10 times more valuable to the marketplace.

There is no such thing as the best programming language. It is silly to think so. Different languages are best suited for different tasks. Good designer is the one who can select (and use) a good tool for the job at hand.

Or, if he doesn't have a tool - he/she can create one.
Good example - Perl was created by Larry Wall because he needed a better tool to do his job.

Today (as always) we face 2 conflicting requirements:
  - systems get larger and more complex
  - systems need to change more often - and changes should be made faster

Let's think about amazon.com as an example. The system servers millions of clients, and the number of clients constantly grows. At the same time the site changes all the time introducing new better ways to work with clients.

When things start to change faster and faster - simplicity becomes a "live or die" requirement.
In many situations you literally don't have enough time to make things "right" or complex.

What do you prefer - a simple system which does the job - or a system which is architectured "correctly", - but never quite works, and can't be adapted to your requirements fast enough?

So it is not about "making it right" any longer. It is about making it simple to change and adapt.

Software systems are like live organisms - they have many imperfections, and they always growing and changing. By the time you make them perfect - they usually get thrown away and substituted by other systems.

What makes more sense to you - making things right, or making things work and be useful ?

I've heard many times that Object-Oriented paradigm is the best invention since starting the programming era. I agree, it is a great thing.

I also believe that the best thing about OO programming is not objects themselves - but the culture of structuring the application in a way that helps you program and maintain the application. Experience in OO programming changes the way you think and makes you a better programmer.

Or a worse programmer! Because when people get very familiar and involved with objects, they start creating them everywhere - even when they are not needed at all. This happens a lot when programmers use graphical tools (like Rational Rose) and UML diagrams to structure their applications. These tools make it extremely easy to create classes. And programmers get in a habit of drawing new classes every time they need some functionality. It is easy and addictive. And this occupation is well paid (called "Architect").

As a result I've seen a program, which instead of simply printing an html tag was going though a process of creating a class for the tag, and then classes for all parameters of this tag, and then running methods to to get the tag together and print it out. This is like instead of saying "The height is 6 feet", you would say: "The height is exp(ln(6.0)) feet".

Dinosaurs.

Big complex systems remind me of dinosaurs. Do you remember what happened to them? And who is now dominating the Earth?

The hierarchical structures of OO programs can be very useful for some applications. But not always. For example, in big organizations you simply can't get everything into one hierarchical structure. All you can do is establish some pretty liberal general guidelines and rules of communication. Read more here: distributed_computing.html.

Let's say you started a web site with just one page. Then you added some more. You working one page at a time. Each page is a finished product. Together pages make a system - your web site. It may be slow incremental growth. And this growth is stable, you always succeed, because each step is simple enough and rewarding enough.

This is example of evolutionary development. You start from a simple bare bones single function utility. Then you write another one. And another. You add features. You combine them together - and finally you have a product.

You allow the program to grow as a child.
When the child is born - you don't know exactly what it will grow into.
May be the product itself will not be a success - but one of the components will.

The art is to structure the development process into a set of easy and rewarding small steps.
The art is to structure the development process so that the product starts to be useful at early stages. And then it grows and improves with the feedback from users.

If software is simple and useful - it can start with a 2-week project - and then grow as a child.

If software is not simple or not useful - it will be very difficult for it to grow or even survive, regardless of how much time and money were originally invested, or how "right" was its design.

I wrote this - and then found that I was not the first to formulate this. See for example www.dreamsongs.com/WorseIsBetter.html - "Worse Is Better" by Richard P. Gabriel.

When I was a student (in Moscow, USSR, 1975), we were sent to the suburbs to collect vegetables (carrots). The task was simple. We were separated in pairs, and each pair had a ~120 meters long row of carrots to collect in 1 day.

There were 6 pairs starting side-by-side like runners at a sport competition. Although we were crawling on our knees, not running. At the end of the day nobody finished their norm. In fact, most pairs haven't even finished 50%.

This continued for several days, until our manager (who was a 1st year post-graduate student) made something very simple and very magical. Instead of having us compete side by side along 120 meter rows, he gave each pair a set of 6 rows 20 meter each.

So now each pair had the same amount of work as before, but it was structured as a square divided into 6 short rows.

Here is the day norm before and after this restructuring:

Before:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

After:

xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
 

All 6 pairs before:

111111111111111111111111111111111111111111111111111111111111111111111111
222222222222222222222222222222222222222222222222222222222222222222222222
333333333333333333333333333333333333333333333333333333333333333333333333
444444444444444444444444444444444444444444444444444444444444444444444444
555555555555555555555555555555555555555555555555555555555555555555555555
666666666666666666666666666666666666666666666666666666666666666666666666

All 6 pairs after

111111111111222222222222333333333333444444444444555555555555666666666666
111111111111222222222222333333333333444444444444555555555555666666666666
111111111111222222222222333333333333444444444444555555555555666666666666
111111111111222222222222333333333333444444444444555555555555666666666666
111111111111222222222222333333333333444444444444555555555555666666666666
111111111111222222222222333333333333444444444444555555555555666666666666

You would say - so what's the difference?
Let me tell you.

Why has this happened?

I don't know the scientific explanation. But I can tell you how it felt.

You start working on one row - and pretty soon you see that you can reach its middle in a short time. So you decide that you make to the middle - and take a short break.

But when you have gotten there - you could see that it is actually very easy to finish the row - and then take a break.

And when you made 1st row - you see that now only 5 left. So you estimated how long it took you to finish the previous row - and you can tell when you will finish the next row. etc.

The work started to feel manageable. And everybody rather enjoyed the process. It was addictive.

So, do you want to increase your effectiveness 3 fold?
Then plan your work as a set of simple manageable self-contained and self rewarding steps.

Let's say we have 2 solutions to a problem:
  Solution "S" - simple, easy, cheap, flexible, reliable.
  Solution "P" - politically beneficial, although very expensive, new (not proven to work), hardest to implement and maintain.

An individual developer usually will select the "S" (simple) solution.

A manager in a big organization will, on the contrary, always (ALWAYS !) select the political ("P") solution.

Let's formulate this as The First Selector's Law:

Please note, that managers are NOT stupid. They are doing the right political move in order to survive in the organization, get more people under them, get promoted, increase visibility and weight of their department, etc.

Yes, they are doing the right thing politically, right thing for themselves. This "right thing" is NOT the best thing for the organization or the product, but managers will never admit this. Instead they will claim that their actions are in the best interests of the organization.

Quite natural consequence of this law is that in spite of trashing millions of dollars, managers usually don't lose their jobs. On the contrary, they usually get promoted, and receive more resources (people and money) to continue their work.

Similarly consulting firms always propose complicated solutions with lots of manual labor.

For example, a solution on the cloud using multiple services and needing multiple people to configure and maintain it.

Why? Because if they would offer a simple reliable low-maintenance one-script solution, they wouldn't be able to charge a lot of money for it, and they wouldn't be able to convert it into a long (many years) maintenance / development project.

Practical advice:

Why not? Because you will create a conflict.

Manager will have to chose between keeping you and making the "right thing" politically.

Do you really want to get fired?

  - use 2-weeks criterion and ELF formula to avoid going "heavy weight" path
  - use 90/10 rule to slash-off unnecessary requirements
  - select the best tool for the job (or create one)
  - the system ideally should include not only tools to do the job, but also tools to change itself to fit to changing requirements.
  - let the program grow as a child.
  - plan your work as a set of simple manageable self-contained and self rewarding steps.
  - be careful with promoting simple solutions in a large organization.

------