Wednesday, July 17, 2019
 Now reading ...
Mar
10
Tue
Posted By Subodh on Tuesday, March 10, 2009
2125 Views 6 Comments


 

A design is a design 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?

 

1990 Bubblesort in GWBASIC 1995 Bubble Sort in QBasic 2000 C# Bubblesort

 

 

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?”

Fundamentals of Core design 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.

Apples and Oranges 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!

Categories

  
 You may also be interested in
  
 Comments & Discussions

  • Gravatar
    Ritzy Thursday, March 12, 2009 at 12:27 AM
    Re: An ID is an ID. A design is forever. Part I
    Nice Post Sir for everybody including rookies and seasoned ones.
    By the way, I can sense the origin of this and the frustration which is driving you to rant about this.
    But then, had every developer been so smart and vigilant, all support ops would be out of businesshappy

    • Gravatar
      Subodh Thursday, March 12, 2009 at 1:23 AM
      Re: An ID is an ID. A design is forever. Part I
      There is rarely any support for anything open source; Is there? Of course this is a grim economy but is that a justification enough for writing bad code? Or, for that matter making big waves about something so clumsy?

  • Gravatar
    Prasanna Thursday, March 12, 2009 at 8:05 PM
    Re: An ID is an ID. A design is forever. Part I
    Good post. But I dont completely agree with some parts of the article...
    Lets say I inherit a product, and the developer uses a style different from mine, then I'm not sure if I should be following the same style as the original developer or a different style.

    Also, having to follow the same sort algorithm or to think of WM_PAINT or the fundamental at all times is not feasible. Paradigms change. The fundamentals also change. One should be ready to accept the changes and also try out newer algorithms.

    Ah! Now you want my email too sad(

    • Gravatar
      Subodh Thursday, March 12, 2009 at 8:47 PM
      Re: Good post. But I dont completely agree with ...
      Disagreements are welcome ...
      >Lets say I inherit a product, and the developer uses a style different from mine, then I'm not >sure if I should be following the same style as the original developer or a different style.
      The point is ... if the developer used a style it would be so easy for you. That is the whole intention. The problem crops up when the developer did not use a consistent style

      >Paradigms change. The fundamentals also change. One should be ready to accept the changes and also try out newer algorithms.

      Paradigms change, fundamentals never do. There may be a newer way of doing things which if you learn quick enough, feel free to use it. Just don't copy paste without understanding. Being able to repeat a code blindly is a habit that comes only when one has mastered something.



      • Gravatar
        Prasanna Thursday, March 12, 2009 at 10:05 PM
        Re: An ID is an ID. A design is forever. Part I
        >Disagreements are welcome ...
        >>Lets say I inherit a product, and the developer uses a style different from mine, then I'm not >>sure if I should be following the same style as the original developer or a different style.
        >The point is ... if the developer used a style it would be so easy for you. That is the whole >intention. The problem crops up when the developer did not use a consistent style
        Fine. Another real life situation: developer 1 uses a style, developer 2 inherits it and uses his style for new things, we already have 2 styles and if a new developer comes in... well, in a more practical sense, i guess we have the generic programming styles (paradigms) for exactly this reason. Again, it is tough to say what is the right style to follow.

        • Gravatar
          Subodh Thursday, March 12, 2009 at 10:42 PM
          Re: developer 1 uses a style, developer 2 inherits it and uses his
          Developer 2 is supposed to follow Developer 1's style. Unless he's ready to re-invent the wheel.

          Real life example, Rick changed my curly braces from a huge file to his *nix style braces that open at the end and close just below the if or the for loop. Yeah, he did that using regex but imagine the horror when I checked out from CVS and saw the diff? To make matters worse, such a senior programmer/architect what not insisted that is the correct programming practice?

          To me, it was just nonsense; "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 "
          In the same vein, if there are multiple developers sharing /developing the code , make sure it is consistent with the flow.

  
Locations of visitors to this page Clicky Web Analytics 

Subodh's Blog Rating

 

DISCLAIMER

The opinion expressed
on this page 
is strictly that
of the page author
who has a
habit of animating
day-dreaming
and
fictionalizing
out of thin air.
 

The contents of this page
have not been
reviewed 
nor
approved
by 
Yahoo!

 Follow this blog
  
 Tag Cloud
  
Archives
 

Top 5 Posts of Last year
Copyright © 1995-2009 Subodh Shakya. All rights reserved.{Powered by SpeedBlog}