Don't design without a reference. Review on General Tips on Software Design

Dear reader,

I don't want to repeat what I mentioned in my programming tips article since these two go hand in hand. A good designer has to be a good programmer and a good programmer has to be a good designer.

And I am talking of world class programmers. I am not talking of mere implementors who translate specifications into code like a parrot.

Now, designing is not easy, I would say however that designing much easier than programming. Because you need not and should not care about the details. It is only attention to details that pains the brain so much.

And I really don't think design needs much experience. If you have the right approach to solving problems, it is enough. So typically you find people with high IQ ending up becoming good designers even if they have no experience . In fact most good designers I have met don't even have a computer science background.

But to translate the good design into a working product, you need a programmer who knows the'why' part of design. Ideally and theoretically you can produce great software with a design expert and an expert programmer.

But somehow this does not work in real life. I do not know a single instance of this unfortunately. Good designers, why even professors who publish papers also write code. Angelos Keromytis, John Ionnadis, Vipul Ved Prakash, all world class cryptographers they write code.

I will give you some hints on design. Again as I mentioned in the programming article, it has to come naturally. I cannot teach you.

1) Be willing to question convention, at the same time learn from past people's mistakes

2) Avoid using threads as much as possible

3) Do not optimize for performance( unless you have tested it yourself)

4) Use the best tools for validating your design and choose the right programming language

5) Throw the design patterns concept out of the window

6) Don't care about high level design and low level design much, do it just to satisfy your boss but be aware that they are best written after you finish your coding. It does help to have an architecture document in large projects though

7) Cut the team size by half or better, 1 / 10 th. More programmers give the game away. You really don't need more than two smart people to write great software. Skype was written by two people. Most other stuff are written by one person. OpenSSL was written by two people.

8) After the first cut of the product, get more people to maintain it, enhance it and support it. gcc is supported by large team of people. So with apache, linux, freebsd and so on. Once the size becomes unmanageable, more people are required. But not much design is involved after the first version. If your design is bad, even if you recruit thousand people later, you cannot mend it. But if it is good it is hard to spoil. Fortunately most people don't think originally, so we can cash in on that.:-)

9) Keep it simple stupid. The KISS principle. Don't overestimate the project and blow up your ego. You don't have to design for extensibility so that people from Mars can use it when they come.

10) Most importantly if your boss doesnt think your way or doesn't agree with you on important decisions, and especially if he suffers from an inferiority complex, then take my word. You cannot do anything. If your job is important  just do what he says. Otherwise just go to a different team. The best situation is a boss who trusts you a lot and never interferes.

Hope this helps.