About Large And Complex Software

It’s been a while from the last post as usual. This time I’m back about a topic we have discussed in the classroom with the instructor about Large and Complex Software. He said that you should design, write UMLs, create comment blocks (70% comments and 30% code) and write documentation for complex software. I opposed him that we don’t know how to write large and complex software.

My instructor is a great one, he is really knowledgeable and has a great experience in developing software, so I should believe him when he tells me so, right? Because the software of Boeing or the space shuttles were pretty complex right? We design them too. So how could I oppose him. From my experience software does not start complex, it evolves into a complex one.
Yes, I said it. I believe in iterative ways. I play chess and try to foresee the next moves of my opponents. I plan for 5 to 6 moves ahead, yet I don’t really know how my opponent will react. According to his moves I may win in 6 moves yet if he makes a different move, I may lose in 2 moves. Software is similar; you plan before as much as possible but recent events may cause to change you your moves. That’s why you can never create a large and complex software. We are human after all. We cannot see all the effects of our choices before we make them.
You all know Internet, right? The World Wide Web that connects the World! How many of you know that Internet was no more then a joke and hobby to some when it first started. It was not something that telecommunication companies even mattered. Because they had such a “bigger” project going on that would change the world. Yet Internet prevailed. How? Because it was iterative. It moved on, adapted to new requirements and improved itself.
That’s how you develop large software too. You have a dream with lots of unknowns. You start with baby steps, later it rolls faster just like a snowball going down the hill getting bigger every second. Large complex gets larger with every chunks of feature written to it.
But it always get harder to maintain it. That’s when good documentation and architecture gets in: Maintenance. In a previous post I had discussed that architecture only mattered because it is always faster to modify something then writing it from scratch. Yet we don’t even know what is good architecture. You cannot educate someone to be a good architect. You can make him your apprentice and let him practice to make his skills perfect.
Software Architecture and Design (yeah, with uppercase letters), is not taught like maths. It does not have strict formulas. It only have some guidelines which sometimes does not lead to better results too. Consider the comments. They are helpful, directs you, gives you an idea of what the statement does right. But it does have a flaw, which is not seen easily: It might mislead you. Consider a public class variable, which has a comment block on it saying that this variable is a private and static. So which one is true? You see? Codes keep change yet, comments once written tend to become outdated. Also think for a second, when do you want to write comments? To explain yourself, right? Why do you need to explain yourself? Oh yeah, because you have done something wrong right here, or you have made a hack there which was not very obvious. So sometimes if you see the need to comment, that perhaps you are doing something wrong.
We are human and we are prone to errors. We don’t know what is good design, how we can develop large and complex software. Sometimes Boeings crash, or Challenger cannot reach the space because of major malfunctions or Windows’ firewall lets some viruses in. Next time, the same event will not happen with the same reason. It’s already fixed and our “large” software just became “larger”! Do you think that the first Boeing that flew was really the first?
We are empirical, we try and err and make it better, we start with small parts, we put them together, check where we have arrived and keep adding more smaller things, making it bigger and larger.