Anyone related to software performs some design decision or other in their daily life. Sometimes we know that we are designing or sometime while coding we take those decisions naturally/unknowingly. Point is, any constructive work will have to choose among various choices to create/design something new, software is no exception.
I have realized over the years that the choices that we make can not be bound to very hard and fast rule cause they tend to change w.r.t context. And this is why it is so interesting.
For example, if we find some list of numbers to be sorted, we can say, we shall use QuickSort. Now think that these numbers are stored in a large file of 4 GB size, can we read all the numbers in memory and perform quick sort? We probably need to split the large file in several smaller files and perfom something like a mergesort. So the context really changed the decision.
I remember one time we wrote a perl function which will read all the lines in a file and perform some operations between lines. Lets say in one line, we have the cost of journey from A to B and in other line we have cost of journey from B to A. This program will combine the both way journey cost and produce one line (out of 2) after adding the costs in both ways. It was working everywhere, suddenly one day it stopped at some places. Problem is - if the file size grows large, out-of-memory error was coming.
How did the file size grow large? This program is supposed to run every after 15 min, but at some sites, customer did not run it for a week and when they re-enabled it again, it failed....
Again, context broke the design decision we took.
Around a year back I was reading some site and it was mentioned how one of the top most architect of microsoft takes interview. It was very interesting to see that he asks "design a house" type of question. The moment candidate draws some square box on the board and mentions the specifications as 16feet long, 13 feet wide, 12 feet high living room, he is almost out ...
Why ? –
Because the candidate did not ask the "context". That house was for a giraffe and not for the interviewer. So a 12 feet high becomes too less for the animal.
A good developer will always ask these questions before writing a single line of code. If he assumes something, he would also write down the assumptions.
Agile methodology tries to solve this problem. At first, it produces a basic (you can read it as crap) version of code with loads of assumptions. Show this to the user, and give them a shock, oh my god, these assumptions are not gonna work in my env! Now we are talking, we know, it is not going to work in your env, let’s note down those assumptions on which we shall work for next 6 months and give us more money :-)
Over the years I am trying to rectify myself on this -- design something and also think of breaking that design cause either today or tomorrow it will be broken by someone else in support/field/customer. Instead they find it, its better to find the problems by the creators themselves.
