Simple Is Good:
On this page:
2-weeks criterion and ELF formula
"do we really need it?" (or 90/10 rule)
applicaiton or framework
best tool for the job
how to design complex systems today - "live or die"
When Object Oriented programming can cause problems
Six small problems is better than one big
Simplicity vs politics
|selected quotes on simplicity||home - top of the page - email|
"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
|2 weeks criterion and ELF formula||home - top of the page - email|
I believe you should find simple ways to do things.
If you can't see that you can complete the project in 2 weeks - don't do it immediately. Think first.
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.
|"do we really need it" or 90/10 rule||home - top of the page - email|
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.
|For example, let's say you need a report. So you asked two programmers
( John Hacker and Bob Architect ) to make it.
John Hacker hacked a script in one hour and emailed you the report. You looked at the result - and realized that your original requirements were not correct. So you asked to make another report - which John emailed you in next 10 min. After going back and forth 5-10 times you were completely satisfied. You could customize the reports providing some simple parameters on the command line or in a short text file. John sent you all the scripts along with a short README instructions text file. He also put the scripts on the web server and made a simple text-only web page so that you can access the scripts using your browser. The results may be sent to you via email or shown on the web page.
Bob Architect, on the other hand, is a true believer that if you do things right - it will save you effort in the long run. So he started to draw UML diagrams using Rational Rose or TogetherJ to make proper Object Oriented design of the "report engine". He also decided to make a proper GUI interface. When John already went through 10 revisions, Bob was still busy thinking about distributing responsibilities between his classes and interfaces, and was very proudly telling you about his elegant design of "request manager", "cache manager" and "report manager", etc., etc. Finally he made the application work - but it took him 10 times longer. And when he finished - you already needed different reports. So you asked him to change the reports - but only found that your new requirements don't fit well into his object model, so he will have to start from scratch. Does this all sound familiar?
In this scenario, first programmer sacrificed some features (GUI, OO design) - but got the job done. Yes, the approach was not very pretty. But it was fast, simple, allowed to move forward, and next time can be changed as necessary.
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.
|application or framework||home - top of the page - email|
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.
|Best tool for the job||home - top of the page - email|
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.
|How to design complex systems today - "live or die"||home - top of the page - email|
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.
|Perfect garbage||home - top of the page - email|
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.
All real working systems are far from being
Perfect systems are garbage.
What makes more sense to you - making things right, or making things
work and be useful ?
|When Object Oriented programming can cause problems||home - top of the page - email|
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||home - top of the page - email|
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.
|Evolutionary Development||home - top of the page - email|
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 who formulated
this. See for example www.dreamsongs.com/WorseIsBetter.html
- "Worse Is Better" by Richard P. Gabriel.
|Six small problems is better than one big||home - top of the page - email|
When I was a student (in Moscow, Russia, 1975), we were sent to 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 was 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 - but it was structured as a square divided into 6 short rows. Here is the day norm before and after this restructuring:
All 6 pairs before:
All 6 pairs after
You would say - so what's the difference? Let me tell you.
This day all field was finished by 2 pm ! !
It took only 5 hours to do what before was taking 2 full days (16 hours) ! ! !
This is more than 3 times faster !!
Why 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. And you estimated how long it took you to finish the previous row - so 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.
|Simplicity vs politics||home - top of the page - email|
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:
Managers in big organizations ALWAYS reject
simple proven solutions
in favor of new hard and expensive solutions.
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 ! This right thing may be not the best thing for the organization or the product - but managers will never say this. Instead they will write documents striving to prove that they are working 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.
Never try to convince a manager to use "S"
solution instead of "P" (political) solution.
Why not? Because you will create a conflict. Manager will have to chose
between keeping you and making the "right thing". Do you really want to
|Practical advice||home - top of the page - email|
- use 2-weeks criterion and ELF formula to avoid going "heavy
- 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.