Somebody said, "The top is always vacant" meaning thereby that you can always work hard and reach the top. Unfortunately, in case of our country (and particularly in software development), the middle part is also scarcely populated. Just to give you an example of the quality practices, here is a slightly modified example of code from PTV Marketing System developed by a local ISO 9001 certified company and the largest software house of its time in 1999-2000:
dim jugar as boolean dim shazia as integer if (jugar = true) then shazia = 1 msgbox "Khatarnak Shakeel" end if
Scott Meyers in his book "More Effective C++" gives an example of some weird code and says, "Such developers should be caught and punished till they either mend their ways or cease to exist."
Needless is to say that the project was never managed properly, the customer was annoyed to the extent that he took it to another vendor and in the end the code had to be re-written by a duo of local Ramboes, Salman Kasbati and Mateen. They properly ended the project and managed to get the last installment of the payment from the client.
According to Microsoft Secrets, Bill Gates holds the view-point (and not many will disagree) that design documents shouldn't be separate from the source code. Chris Peters said, "…a developer's job is to write code that we sell, not to spend time writing high-level design documents." Bill Gates supported by saying, "One document. One. It's the source code. It's the one place you go. You learn everything there, and you know everything there. " If you come from the open source background (or even something like XP) you will understand what I am trying to tell. However, if you are like me and come from the top-down approach to software development, it's difficult to digest. Experience will teach you (just be attentive to the lessons of time)!
Most developers write code as if they had been forced to; most probably at gun-point. Some basic things like variable naming, duplication of code, indentation of lines aren't taken care of. You will find developers making large claims that they know .NET or J2EE or Java Security API or System.Data.SqlClient assembly, etc. but if you read their code you will feel if they have vomited. Trust me when I say that it’s not something to be proud of if you can read an article in MSDN or Javadocs and can imitate in your code.
Nothing makes a fellow developer as uneasy as what it takes to understand and debug poor code written by someone else. I wish every software house forced fresh grads read Code Complete (or something to that effect). To improve the standard of code, the practice of code review should be strictly enforced.
Lastly, many times I have seen code like this one (again Visual Basic):
dim rs as adodb.recordset
Set rs = new adodb.recordset
Set rs = dbConn.execute ("select * from myTable")
Can you see what's wrong? What's line #2, after the declaration of rs and before getting the recordset, doing here? Eric Lippert attributes such code to cargo cult programming where the developer has seen code like this and is invariably following it everywhere, without understanding what each line is doing. Or more importantly, is each line required? Is there a better way to do this?
My earnest advice to fellow developers is:
- For God's sake, write code that speaks well of you: You are an engineer; be proud of what you build!
- Understand what you are writing: Don't be a cargo cult programmer!
- Stop running after buzz words: know the basics first, go on to understanding meanings of the jargons, then learn designing skills and only then move to specialize in one particular set of technologies!
- Get code reviewed: Introduce the practice of Code Reviewing in your company!
No comments:
Post a Comment