I never quite understood why it takes people n different iterations to get a design right. No, it is not surprising that they do understand Object Oriented Design, it is downright irritating that they learnt OOP all through their founding years, graduated in CS, have been doing this for life and still write software like every damn piece of their code is a masterpiece in itself. Look, I have no issues to your claim of having mastered the Object Oriented paradigm. I don’t even care how you code. I don’t care you know your algorithms or not. I don’t care what language you program in. I need to know you’d be consistent.

I start my tirade with Part I of what I think every software Developer, Architect and an engineer needs to know. I’ll complete my rant in three posts and if you feel strongly, weekly, lonely et.cet.ra,  for/against anything, please feel free to comment.

A good code is a good code

One should be able to repeat code, line by line, tab by tab and semi-colon by semi-colon even if its being repeated after a gap of 10 years. The reason? A bug free, highly dependable code that can be reused again and again. Need an example?

Notice a pattern? It wasn’t that I wasn’t aware of Quick Sort or Shell Sort or other ridiculously  complex sorting mechanisms involving head pointers and tail rudders. There are n ways of killing a rooster. Including  .Sort();

There is none good or bad among nays. But if there is one that you can remember and punch without looking at your screen or keyboard, hit F7 and it compiles without an error, that is the best code. That code may be as complex or as simple as you want, it just needs to be your habit. You should be so consistent with that code that you could ramble it on in your sleep. That,  according to me is a good design. Not some fancy stuff you copied from google to sort a list of nxm dimensional array.

Consistency across all tiers

Writing code isn’t difficult. Writing a consistent code is an acquired trait. Using that trait across n tiers is not an art. It is the pinnacle of good design. Whether you’re designing classes or databases, writing stored procedures or designing high performance applications, the way you approach one tier will be reflected on others. Consider this; If a person writes haphazard code in a language that he/she is very good at, he/she is guaranteed to writing even more of a reckless nonsense when subjected to an alien language. A structured approach is one thing, multiple school of thoughts which misguide, confuse and confound the software developers towards a single rigid right approach is an endemic, a cyclic trap to be avoided at all costs.

Listen up developers and architects. There is no such thing as one right approach. If there is anything closest to such a thing, it is your consistency, nothing else. If an interface were to be perfect, it would not be reusable, nobody would use it because it is so rigid, it cannot be modified or used for anything else other than what it was supposed to do. If on the other hand an interface is reusable, it would have to be imperfect  so that it allows minor modifications or extensions, in which case, it definitely allows for inconsistencies that were not thought of at the time it was designed.

So how, you as a developer or an architect can ensure you have a common, consistent approach be it designing systems, writing a stored proc or even coding a consumer class?

Know the fundamentals

This is not something you would be asked when interviewing for Google or Microsoft. This is for your own good. Without thinking much, tell me in one line, “What is the first thing you do when you write a class?”

Much in the same vein,

“What is the first thing you do when you create a database table?”

“What is the first thing you do when you write a console application?”

“What is the first thing you do when you write a Windows application?”

“What is the first thing you do when you create a website?”

No, I’m not looking for Stroustrup kind of answers about the inevitability or mutability of an object or a class. Neither am I worried if I’m a friend or publicly retarded. I’m asking something plain basic.

What is the basic structure, the meta-base of a class, a database table, a console application, a windows application, a website or whatever it is that you do that you would create as soon as you lay your hands on the keyboard and your favorite editor?  You do have a basic fundamental structure right? The one you would write even without knowing anything about the purpose of what you were going to do?

If you did not create an ID column in your database table, you should probably not even read any further. If the class you created did not have a uniquely identifiable (and thus an equality operator) metadata, or teh default properties and methods, lets just forget we ever talked about OOP. Ever! What is needed for an object to access a middle tier? If the console application doesn’t talk to the console or error pipes, there is no reason for being a console application, right?Did you think WM_PAINT? Did you think Global? All this while remembering to write the same consistent code every time. The same, consistent approach every single time.

So, why am I harping about completely different things and advocating consistency across apples and oranges?

The answer is simple. If I am trying to understand your code, it is the same as you trying to understand your code after say, 5 years. If, for a given problem you were to write different codes at different points of time, trust me, you’re wasting a lot of your own time, the client or company who’s paying for your time as well as re-inventing the wheel. The fundamentals do not change. Nor does the basic fundamental code.

Apples and Oranges all have a seed, flesh and skin.

So does your code. There is the meta-base, there is the behavior or the operator, the methods or the properties, the configuration or the initialization and the exception handling that are common across all the coding you do. It has to be. If not, just make sure you never ever code for me, nor should I ever be subjected to looking at your code. Not for the code, nay for the design. Certainly not for whatever else you engineer.

Do you call a CreateThread every time you need a new thread? Do you create a new mutex every time you need it? Do you have a framework of your own? Do you derive your classes from exception base classes? Do you have to think before writing a Singleton pattern? Do you scoff when you see the brackets on the left side or the right side, aligned or inline & closed?

There is no right answer to any of these questions. There is one common thread though. There are rules. And they are uniquely, consistently yours. They exist invisibly but they definitely reflect your coding style, your design style, your thinking process and even how you organize your hard disk. Hey, if you had the last 10 minutes with your hard disk, would you know what files you need to copy?

Here’s hoping you’ll wait out for my next rant!