There’s this overemphasis on reusable software where you never get to open up the box. It’s nice to have these boxes but, almost always, if you look inside the box you can improve it and make work better once you know what’s inside the box. ~ Donald E. Knuth (Excerpt from Coders At Work.)

Second excerpt I posted from the book, Coders At Work that has so deep meaning.

Even though we use so many different libraries and APIs both lower and higher level, if we don’t know what these APIs and libraries do or how they work then, it’s just like using one of those anonymous black boxes with lots of magic.

Software engineering and programming are such an inquisitive fields that there are always unexplained avenues for gaining improvement. I may not have proper authority to fully capitalize the previous statement because being relatively new to programming (couple of years or so of professional career), there are so many unexplored horizons of software development that I still need to explore.

But every time I write some code and after sometime, I personally feel that the code I wrote sometime ago is really awful and dirty. I have to admit that most of my personal projects that I did alone was kinda failure and/or bizarre and no doubt they have taught me lessons I will never ever forget in my life.

I reviewed the code I wrote just few months ago and I was able to extract so many mistakes and would be bugs that I wrote that code again. And may be after few months, I will do same again. But this cycle of writing bad code and after certain time getting to feel how erroneous me and my code does make me quite happy and I can make self comparison how am I improving as a programmer that does not just code but write clean and testable code . But I am really loving this vicious cycle of unsatisfactory code.

If you are new and kinda enthusiastic programmer then, I guess you have also experience similar and/or related cycle of dissatisfaction and are always searching to learn and implement something new. It would be really nice if you can share your experience too.

I am going through the book named “The Object-Oriented Thought Process (3rd Edition) (Developer’s Library) by Matt Weisfeld”. I got some interesting facts in the chapter 9 “Creating Objects” of this book which I want to share. Being a software developer, we know that we always want to create a stable system. The 1962 article titled “The Architecture of Complexity” by Nobel Prize winner Herbert Simon noted some quite interesting characteristics of the stable systems:

• Stable systems have hierarchy. Each system is built from a sub-system and each sub-system is still built from another sub-system forming basis for functional decomposition. This approach has been used in structural approach also.
• Stable system is nearly decomposable.
• Stable system evolves from the the simple sub-system that have worked.
• Stable systems are always composed of only few different kinds of sub-systems

Another fact I want to share is about the design decision that is required to be made. We know that a system needs to be loosely coupled and highly cohesive. But what should we do for achieving this? Three points have been proposed by the author:

• Which objects collaborate with each other?
• How many objects participate in each collaboration? (This represents cardinality)
• Is the relationship mandatory or optional?

I really recommend this book to any developer who wants to enhance his/her knowledge about the object oriented development.

One can download really cool programming foundation bool from codebetter.com. Moreover the book is free and it is worth to read for all developers of my level i.e. college students or enthusiast learner. The link is here. Happy programming and reading