Continuous Learning

There are some interesting posts lately about what programmers like and don’t like to do, and what programmers can’t do. If the below are all true, just what the heck do programmers really do?

I will let you be the judge

Scott Rosenberg says programmers like to code:

And programmers, as I quote Larry Constantine in my book, programmers are programmers because they like to code — given a choice between learning someone else’s code and just sitting down and writing their own, they will always do the latter.

John Rentzsch responds saying programmers don’t like to code:

… they like problem solving.

If programmers liked to code, we’d all be writing in machine language to this day. You can write that stuff all day and get precious little of the real problem solved.

Rafe Colburn says even good programmers can’t avoid coding more than necessary:

There are days that I am just not that productive and all I do is browsing the web to absorb as much information as possible. Below are some of my web clippings and learnings.

A Large Monitor is Actually Cheaper Than a Small Monitor

Steph has done one of the best jobs justifying a business expense that I have ever seen. In this article, he takes you through how programmers work, and how the increasing of screen real estate can be translated into numbers of hours of productivity increases. One can create a business justification template from this article.

• State the benefit - why type of benefit that we can anticipate from the purchase
• Describe the AS IS situation - where we are, how we work, etc. (provide visuals if at all possible)
• Describe the TO BE situation - how we can improve the AS IS, where we can be, etc (provide visuals if at all possible)
• Measure the benefit of TO BE - determine formulas on how to measure the benefit, and plug in the numbers.
• Describe both the ideal case as well as the worst case scenario - achieve a good number even in the worst case scenario
• Describe the intangibles besides the directly measurable benefits

Bravo, Steph!

As promised, there are a couple of software myths that I think are not covered in Robert Glass’s book, and this post will talk about one of them - that software development equates to building constructions. This is a very popular metaphor - first you design, and then you build; just like when we are constructing a building.

Even though this metaphor is popular, in reality it actually is very dangerous and misleading, because it degrades the partnerships between the technical folks and the non-technical (i.e. business) folks and threatens to destroy the values that software projects should create in the first place.

Let me tell you why.

Now - Others have previously pointed out that Software is not similar to building construction, as well as pointing out the horror of command & control style of management. However, while these writings struck a chord with me, they are meant for technical folks rather than business and non-technical folks, when they should really understand the reason and the impacts. In the IT world, business folks matter a lot, both for the project successes and for the general well-beings of the project teams, and it is critical that they can understand the differences. So I will attempt to explain this in a different light. Either I will be successful, or someone else will continue to pick up the torch. This will not be a fast process, but I will do what I can to help.

Because this issue is very important.

We can easily see the similarity between software engineering and building constructions, especially if we are attempting to create something complicated. The famous software project management guru, Steve McConnell, draws a clear parallel when he emphasize the need for proper planning to ensure software success (paraphrased below):

Writing software is like building houses. (Steve actually provides a few different metaphors but appears to like this the best) If you are building a doghouse, you do not need a lot of upfront planning and you can do just fine. However, if you are building a skyscraper, you most likely will fail without proper upfront planning and preparation. (Code Complete, Second Edition)

His point is very well taken. Similar to building constructions, software projects require upfront planning to ensure success. But that is because planning is in general good for achieving any moderately difficult objective, not because software development is the same as building constructions. For example, proper financial planning will help us reach our personal financial goals easier (or so I have been told), and proper wedding planning will ensure the bride entering marriage happily (or so I have been told).

Steve points out that building constructions is a metaphor, and he puts it succinctly:

Using metaphor is a fuzzy business. You have to extend them to benefit from the heuristic insights they provide. But if you extend them too far or in the wrong direction, they will mislead you.(Code Complete, Second Edition)

The challenge here is that we have already extended the metaphor of building construction too far, especially in the IT world. This is something Steve probably could not have foreseen.

Now - why is building construction a popular metaphor? While I do not know the historical context, my guesses are: Keep reading →

Steve Pavlina just posted an article talking about the chance of becoming a black belt has no bearing on whether or not you would succeed, because success is a choice, not a chance. Most black belts start as white belts, and it takes years of learning to become worthy of black belt. It is the journey that makes it a worthwhile experience.

I have previous written that passion is the one of the biggest indicators for future success, and the true passion does not mean what would you like to do for fun, but rather what would you do after you are done just having fun, and are ready to overcome any challenges. Few people in this world develop true passion for things, and rather they shy away from the first sign of difficulty - I know so myself

Why is that? Is this a human innate nature? Or is this something that we are conditioned to do? Keep reading →

For some reason, there are a lot of myths and misunderstandings about software development. Maybe this is the way it is for all fields, but that would be surprising. If it is just urban legends for outsiders, that makes sense and adds to the mysterious appeal. However, I would venture to say that most people in this field all have different views on what software engineering is, and many of them are simply incorrect understandings.

Robert Glass’s book - Facts and Fallacies of Software Engineering - happens to provide a good source for many of these myths and misunderstandings. Robert has been in the industry for a loooong time, and he has a lot to say on this matter, Keep reading →

I haven’t written in a while because I was involved in an intense short-term project that consumed all my available time. The project has a very aggressive time-line and a very ambitious goal. Even with an all-star cast the project still basically consumed everyone’s midnight oil. After I am done with my part, I had to sleep for a couple of days to recuperate. Some of the people sustained even longer hours.

Now that the project is finished, everyone looks back and realizes that we have just accomplished a heroic effort. That brings to my reflection for the day - heroics.

One of the recurring themes you will find in my articles is that people is the most important part of the software management puzzle. I just cannot overemphasize that. Most methodologies are focused on how to deliver, but simply assume that we will have “quality” people without justification. I had painstakingly tried to argue the opposite - it does not matter what methodology you have, the most important thing is to have the right people. The fact is, top notch folks are not just sitting around the corners waiting to come onto your project.

All above are kinda lost in most methodologies. Keep reading →

What exactly is Analysis? What does analysts do? What skills should analysts possess?

Many people are unable to give detailed answers to the above questions. The term analysis is quite general and hence ambivalent.

This is an issue, because analysts carry influence by the virtue of their responsibilities, and hence the choice of an analyst can sway the outcome of a software project to one direction or another. Unfortunately, the ambivalence of the role does not help here. Often the wrong individuals are placed into such positions, and both the project and the individuals suffer as a result.

I am convinced that finding the right analysts will greatly improve a project’s chance for success. This series of articles is an attempt to address what analysis really means in the grand scheme of software engineering, and what the role bearer should do and what skills they should possess.

All in a Day’s Work for Analysts

Let me first say that there are many strong analysts out there doing great work everyday. A strong analyst is worth her weight in gold to her project. But there are plenty of mismatches too. Keep reading →

One person I know probably has the best work life in high tech industry. John comes to work 5 to 10 days a month, each day working 4 to 6 hours, and yet commands a 6-figure salary, and consistently delivers top notch results in an overdriven IT environment, while does seemingly nothing. I used to be baffled about his results, but I finally realize what type of tricks he has upon his sleeves.

His trick is that he hires the best people he can find and allow them to flourish.Most of his team receives only minimal guidance from him. From first day of hire, each team member acts independently, managing their own schedules, and accomplishes necessary tasks without his awareness. They need very little support or training from him to do their jobs. He was able to live in Managers Nirvana just by making the right hires, whereas many managers are struggling to deliver projects, if not failing outright.

It is obvious that we need to hire the right people. After all, we know we cannot hire anyone off the streets to work on software projects. What isnt so obvious is that you can still hire the wrong people within the qualified pool. Your ability to deliver might just depend on a critical hiring decision. As Johns example shows, the extra attention here will give you extraordinary returns.

Quality versus Quantity

Lets start with a simple fact on productivity gaps: Keep reading →