More thumb rules

This is an addendum to the other page detailing the fifteen commandments of good programming. While those (or these, for that matter) aren’t commandments in any way (you should look up cetus-links for example, to see the better books or pages on OOP), it’s quite an achievement for a casual blogger like me to get listed on digg. And so for the time being, I’m changing neither the URL nor the title for that post ๐Ÿ˜‰ Also goes to show that there is worth in internet marketing as a concept ๐Ÿ™‚

So here are my “thumb rules” for now:

16) Object Oriented Programming is an excellent paradigm.
If your situation allows you to choose (nowadays mostly yes) between procedural and OOP, choose OOP. It makes your code well organized – not because OOP is great and procedural is not, but because by its very nature, OOP goes that extra step in ensuring that you write good code. You can write equally good code in C, but that happens after at least a year is spent on C. In OOP, on the first day, you are prodded towards writing better code. Any changes to be made later on are restricted to one or two methods or a single class, depending upon the change. (Of course, major changes may need addition of say 50% or 100% code, but that’s not what is referred to here.) The cycle goes โ€“ change in just one place and it gets reflected everywhere without problems everywhere in the system. In general, OOP or not, the bottom line is to do one thing in only one place.
The moment you break up your processing into parts and have each part do only one thing and equally importantly, have only one part doing one thing, then making changes later on becomes very easy. The very simple fact is that the more the number of locations in your source code files that you have to make the change, the more you are likely to break your program by making changes in some places and leaving out some others – this fact, though not obvious during development, becomes the single biggest factor deciding the ease of maintenance of your program.

17) Do not fall into the tempting OOP prefection trap. For example, it is very tempting to make several functions or method members which fetch data into your object each on the basis of a different parameter, so that writing the main application code becomes a very simple affair. You will want to make functions like Customer.FetchByID(), Customer.FetchByName(), Customer.FetchByTelephoneNo() all to populate the Customer object, but it’s a waste if you aren’t going to actually use those methods. It is better to just use the one FetchById() method (or few more, depending on your application) and if the need arises later on, add the FetchByTelephoneNo() etc.

18) Sometimes, it is better to use a “top-down approach”.
Assuming that you are a novice either to this technique or to programming (and both, if you are a small-time user of the RAD IDEs like M$ Visual Basic or Delphi or Borland JBuilder, etc.), you may find that a running program, in whatever state, keeps you going. It keeps you motivated to see something “working” all the time.

I’ve been through those learning stages (just like everyone else) and now I find that although it does give instant motivation, larger programs need elaborate organization and pre-thinking. Since you should not radically change your way of working to a point that managing it becomes a problem, try this out on a small, income-unrelated project having about 5-10 code units (source files) totally.
Go about it as follows:

  • First try writing a few pages of code on paper. That gives a good idea of how things are arranged in your business logic.
  • Then try to do object design down to class -> function / member (without actually putting running code anywhere).
    For e.g.

    Public class Customer {
        String GetName(){
            return "";
        Boolean IsGoldCardHolder(){
            return true;

    The functions are just stubs, no real code is put in them. The entire framework of the application is made ready.

  • Then think how the existing design can be extended if you need to change anything. If you think sufficiently well about the business logic specific to your program, you will see a whole lot of future possibilities.
  • Noting these, refactor your design to make it future-proof. This is the beauty of this metod. You make all the changes to something that is basically text. No worries about breaking code that runs or compiles. Just don’t think of a stage called compilation. Imagine that you are living in an age where compiling is not required (future) or invented (past?)
    The whole idea is to not even think of getting the code to compile
  • After you’ve thought out how all parts are coupled loosely enough to be easily replaceable and elaborate enough to actually do the job at hand, then start putting real code into this framework.
    Personally, I’ve found that I write far better code when I first hit “Compile” only after about 5-10 source files. It gives about a 100 errors at that first compile, but it is a structured method of handling the whole thing, because you then go into debugging mode and stay there till you finish those 100 compile errors.

CAUTION: You can get extremely frustrated if you don’t have patience. That’s why I suggest playing with a small project first before taking on anything big with this approach.

19) Just because the customer is high-profile or very busy does not mean you allow him to loosely define the specs of the program.
He may be a big shot in his business, but when explaining his requirements to you he is an end-user, just like any other end user, most likely very dumb. Therefore, make prototypes before doing actual coding. You cannot be expected to give polished, running programs as prototypes when discussing the requirements!
If you make the mistake of trying too much to impress your client here, you are lowering your own worth and doing rework which could easily have been avoided if you tactfully got it across to the customer that he should refine his ideas a little and see if he wants less/more features. Freezing of the specs is the most important thing in making customized software. If the specs are not frozen, the customer will simply go on asking for more while not realizing that it means work to you – why is he bothered. You have to clearly state that any changes after code is written according to the frozen specifications, is going to cost extra. That’s fair. You are spending time and effort on his work which could have been spent on other financially rewarding projects. He values his time. Why should you be any different?

20) Keep strict time track of what has been changed at what time. The log/speadsheet that keeps the descriptions and time of an issue being raised and then solved is a very important weapon. On a separate log/sheet, keep track of what all has been delivered to the client at what time, preferably making a note of the important things in that release or delivery. There are enough free top-quality Issue Tracking and bug tracking systems out there in both Opensource and proprietary software. Get one of those.

21) Code metrics are very useful even for non-enterprise programs.
Although neither lines of code nor number of GUI screens is a good metric, they are a starting point. It’s much better to use a stanard tools available on the www, which generate standard metrics for your code.
In OOP, number of classes, number of data and code members, and number of lines of code in each code members is a reflection of the complexity of code. Designing normalized classes is pretty much an expertise that you can charge for. Similarly, good database design is a very strong aspect contributing to the value of the effort as is application architecture. If you have to give the source code, commenting and manuals also contribute to the value of the effort.

22) Dont start any coding till you get 25% of the final amount as advance, non-refundable payment. If you don’t get the money during the development period, you will simply not feel like working on it. Worse, if you don’t insist on the advance, your customer may just walk off with the 25% work that you’ve done. Half the guys out there do not think twice before cheating like this. The entire culture that Microsoft has created – cracking, pirating, patching ensures that non-IT customers almost never feel that programs are to be purchased. Although I’m an opensource enthusiast as well, I know fully well that majority of customers don’t seem to have any idea of the fact that it takes sustained intelligent effort to produce a running program. To them, programs have always been free (read *Microsoft’s monopolistic piracy encouragement policy*) and should always be free. But not 1% with the same intent that FOSS advcoates say those words.

23) This is specific to Javascript.
Do not treat Javascript as a “small addon” to HTML/CSS which is a necessary evil. It is not. It is a full-fledged programming language requiring as much patience, study and application of thought as you would need to learn Java, C#, PHP or Python. In fact, since different browsers support different Javascript dialects or variants, it makes getting expertise in Javascript more demanding than getting expertise in PHP or Python or C#. However, since it covers a lot less operations, (restricted to modifying the DOM, window and making HTTP AJAX requests ) it is a significantly smaller job.

24) If you can arrange it that way, have a parallel setup like that of your client so that any customizations that need to be done there can be tested on your parallel setup immediately.

Two solutions are:
Get more RAM and make a virtual machine and test your code in it.
Get another PC and a KVM switch to switch CPUs.

For web developers, there are several utilities out there that allow you to change sccreen resolutions.
Test on every browser, last three releases (of each), with and without Javascript enabled. Searching the web for “standards HTML XHTML CSS” should give you tons of resources.

25) An error in database design is far more annoying and bug-inviting than an error in Business logic or an error in the user interface. So, design your database well, if possible, try to use a database server with debuggable stored procedures – written either in the SQL dialect of that database or in any other lanugage that you are familiar with. For example, certain Java databases do not have PL/SQL or T/SQL or such, but have very powerful Java bindings which allow you to work with the database in a very flexible way.
Subject to the boundary of not pirating, you should use the database which allows you all these features and also runs on the largest variety of platforms.

26) When you’ve been coding for a long time, or some parts just do not work, your head tends to get cluttered with a lot of junk and uncertainty. At such times it helps to take a break and relax. By relaxing I mean free, loosely connected thinking – not exerting mentally or emotionally for a few moments – Restful lazy thinking or “controlled lazing”. It’s great if you can get up and go out of the office for a breath of fresh air, but if you cannot, at least turning away from the computer screen and leaning back on your chair is definitely possible. Do that. Also, as Workrave tells you, hold your palms to your eyes and look into the darkness. That really helps too.

27) Top-quality work is finished with the same expertise and speed that it was started with. It is the non-expert who finishes shoddily what was started well.

28) As someone moving from beginner to intermediate in skill level in/on any particular language/platform, open source is the best way to improve your skills:

  • You get to see how code is organized
  • You get to see good coding styles and accepted conventions
  • You learn how to manage your time and effort around multiple issues
  • You learn to be speedy
  • You learn to see which modification will lead to what in the future – whether a particular feature, module, pattern or architecture will aid or hinder extensibility

29) Going opensource with your product:
Try your best not to release any program as freeware, because that gets you neither direct money, nor does it convey to your users the fact that making software costs time, money and effort.
It also encourages irresponsible consumption – For example, every week your users will spend 100’s of dollars on over-priced gadgets, expensive travel and stay, luxurious transport and whatever else, without once thinking of paying your $20 license fee for a program that they use daily on their laptop over months.
Instead, dual license your code with GPL for strictly non-commercial use and closed source for commercial use for which the licenses are different.
This way people will flock to your program and you get a very strong user base and continuous revenue in support.

You do not have to copy others’ ideas, you do not have to earn only the license fee from the one sale per customer per year – you can get much more support revenue. You do not have to worry about the crackers – what do they crack when the source code is available?

Generally, forks of open source programs succeed only if the initial user community puts their weight behind the forking. If someone tries to act smart, most likely he will be booed out of the community. And if you really look closely at the success of WordPress, Drupal, CakePHP etc., you find that not only are the original coders making good money, the entire community of add-on, theme and plugin developers are making good money as well.
So, you get goodwill and continuous revenue.

It is crucial to know that the GPL is now upheld in a court of law and can be enforced. You can get back damages from a competitor (or anyone else) who uses your code in their programs just because it is freely available from your site.

Occasionally, this sweet plan will not succeed. I have to be honest about that. But that would often be due to some concrete, obvious flaw in either the code, architecture or attitude of the leader/owner.

Also, maybe the small desktop programs segment should not use opensource, since there is probably hardly anything to add in terms of features, and if you’ve made a really good program, probably you do not need to give support at all. In which case, yes, the opensource model isn’t for you.

Then there are many specifics which need to be considered, which vary on a case-by-case basis. However, if you have decided to open up your code, you should use the LGPL or the BSD-styled licenses only if you are feeling really generous.
A BSD-style license essentially means telling your competitor to take your program and sell it by another name.
So, always go for the GPL and dual-licensing.

Finally, if you think that discretion is the better part of valor, I suggest that you join an opensource project and get a feel of how things go and then decide whether or not you want to opensource your product.

Essentially, do not start another project or fork. There are enough of them as it is. Selecting a proper FOSS project is a pretty involved consultancy task.

Unless you are sure you can start an entire consultant ecosystem which does only evaluation and recommendation, don’t add to the huge pile already present and working.

These are my personal suggestions, made out of my experience, you are not guaranteed success or anything by following these.
The author holds the copyright for this article. You may copy and use this article, but not modify or call it your own or anyone elseโ€™s. You must mention that you got this article from this site.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: