Software Development Practices: Part III - The Team Leads

So you are a team lead? Are you a good team lead? The simplest possible explanation of the use of the term good can be "a team lead whose team members want to be like him."

Certainly if you have spent a few years in this field, you have learned the basics and should be considered as somebody who not only can work independently but can also guide others. What skills would be most important? Being a software team lead is no different than being lead of, say, a football team. Your personal contribution to the work itself, your communication/ co-ordination skills and your confidence matter most.

In our local industry, a developer is promoted to this position as early as 1-3 years of work experience. And almost always, for a given project /set of tools, he knows the most. If he gets stuck up somewhere he has to rely on self-help. Not many places are able to retain people with more than 3 years of experience. So where do you learn from?

You probably don't have any one who can guide you in your company; nor you will find someone who can be a source of inspiration that easily. But have you looked outside your company? Are you part of some group that meets and discusses problems and their remedies over a cup of tea, lunch, etc.?

Be a bit social and you will find many people of your age and experience that can help you tremendously in your grooming, knowledge and outlook towards things - people like you who are trying to make a difference in their respective organizations (companies, communities, etc.). Look, for example, at FAST 2000 and the Linux Pakistan team.

Secondly, if you are really interested in software development, have you tried the open source alternative? Open Source software development is a blessing for people in countries like ours. While sitting in the comfort of your home, you can interact and work with the best of the best! There are hundreds of extremely interesting projects going on over the web; such as, Tomcat (Java Web Server), Mono (.NET on Linux), Open Office (Multiplatform MS Office Alternate) and Mozilla (the ultimate web browsing suite), amongst many others. Just to give you an inspirational feeling, read the biography of Linus Torvalds here and the famous quotes of him here.

In my opinion, one of the best places to learn software development is the Mozilla Project. And the best place to start from is to download and see the quality of these applications. Try Win HTTrack and Fire Fox: The Browser, Reloaded amongst others. Then, based on your interest and programming skills search a project of your liking on Source Forge and be part of the development team.

And the third option to help you in improving your knowledge and skills (and also earn a bit of money) is to make a team and get projects from the web. The topic of free lancing is a bit broad (ranging from how to find a project to details on bidding and what not to do). I'll write more on free lancing sometimes later.

Once you are sure that you have extra knowledge that you can disseminate, give reading assignments and informal presentational work to your team. There are many interesting topics like

• Difference between ADO, DAO, OLEDB, ODBC, MDAC, RDO, etc.
  
• Practical demonstration of a two-phase commit
  
• Red-black Trees
  
• Working with Google Web Service
  
• etc.
  

I am only that part of me whom I have met.
(Anonymous)

Software Development Practices: Part II - The Developers

This post focuses on the most important component of any knowledge based organization - the people; or specifically, the Software Developers in a software house. I won't be talking of Quality Assurance Engineers at the moment.

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!
  

Software Development Practices: Part I - Phases

Does any one really know software engineering here? I regret to say that in my experience of 3.5 years, I have come across only 4 or 5 good developers - who really know how to develop software. Yes, this field is new and there are many orthogonal schools of thought in software process. But let me tell you the simplest possible definition of a good process: if it sells and gets used, your code is perfect and your development methodology is the best in the world. On a more realistic note, your code and design are perfect if code maintenance is easy.

Software development is complex because nevertheless, it's engineering and secondly, software by definition is flexible (read "soft") as compared to other engineering disciplines. The most difficult part of the development cycle is to have good project managers. You can't put non-technical managers on top of technical people that easily. Nor you can expect good management skills from coders who don't learn anything in their life except punching keys.

The development phases of a software project taught in university courses are Inception, Elaboration, Construction and Transition/ Deployment. I and my friends usually put a "Rambo" phase just before deployment - when everything is a complete mess and somebody from outside is brought in and asked to re-work on the already lost situation. The Rambo has a reputation of doing incredible things single handedly and more often than once he successfully does what a team of 5 or 10 people couldn't do!

It is an established fact that some developers are 10 times more productive than others. But it's rare to find a significant difference in the wages given to the best developers at a particular level of hierarchy. Additionally, many companies say that they give stock options, employee referral bonus, twice an year technical-financial reviews, etc. but do not hold to their promises. This with other factors effectively results in exporting our best people to developed countries; what's being left behind isn't being properly trained and mentored - resulting in a complete chaos.

Mujtaba Karim, a senior FASTian whom I worked with in CresSoft, says that the real-life phases of software development are Project Kickoff, Wild Enthusiasm, Incomplete Requirements Gathering, Disorientation, Complete Chaos, Promotion of Non-performers and Resignation of Key Resources.

Unfortunately, this is not the story of one particular project or company, some players in the global market and almost all of the local software industry are repeatedly making the same mistakes and have adapted a habit of not learning from the mistakes of others.


"We're going to QueryInterface the object for a magical IGeoff interface that will allow us to do wacky, incredible things. But I don't understand how it works yet because Geoff hasn't told me."
(Someone from Visual Studio Team)

The Alchemist: Beginner's Luck and Warrior's Ending

I came across The Alchemist a few months ago. Somebody gifted the book to my elder brother and I got a chance to skim through it. Once I started reading, I put down the book only after finishing it. And since then I have recommended it to many friends.

The book, written by Paulo Coelho is actually fable of one Santiago - a shepherd who has a dream as well as the courage to follow it. The story of Santiago has important lessons that might go a long way with your life. It's about taking risks, the net result of every effort, the relationship between occurrence of events and improvement in characters as well as lessons on merging with the flow of nature. Don't underestimate the story by my description, it is very captivating. Everything is metaphorical and there are no direct lessons in philosophy. Though some of you might find some marketing elements of story writing in it, it's still a good read.

If you ask me to recommend a single book written by people from our era, based on my limited knowledge of literature, I would recommend "The Alchemist." You can get the book in paperback from Liberty Books for Rs. 250/-.

"When you want something, all the universe conspires in helping you to achieve it."
(The Alchemist)