Comments (2)

By Krishna, July 30, 2009

D’Arcy has a good take about how fast you can do code reviews. As he himself says, the example is a bit contrived, but the point remains: You don’t have to spend a lot of time to do code reviews. Many mistakes can be identified within a few seconds of looking at the code. If you are at the level where you have to spend several minutes analyzing the code to identify problems, then either the code is very good or you are a very bad programmer. Hopefully, the latter is not true, so at that point, you are at the stage where code reviews are reaching a point of diminishing returns.

Doing code reviews is perhaps the fastest method for improving quality in a team. It allows knowledge and experience from the senior members of the team to flow to the junior members, thus enabling them to improve their coding standards quickly. When a team starts doing code reviews, they can easily identify and get rid of the low-hanging fruit in code quality. This, in turn, provides greater stability to the product allowing the team to focus on higher-level tasks. A virtuous cycle follows where the team keeps building upon improvements in quality.

There are many reasons why people don’t do code reviews despite its advantages. One is that many organizations try to formalize code reviews, creating overhead in terms of planning, documentation and follow-up. What should be a few minutes gets planned into an hour-long session with templates to be filled and reports to be registered. Because it takes too long to do one code review, there are fewer code reviews done in total.

Another problem with formal code reviews is that it introduces hierarchy and power structures into the code review activity. Instead of one programmer providing constructive feedback to another programmer, we get metrics collection and performance evaluation. Programmers have to protect their reputation and ego and so try to avoid code reviews.

An important rule is that the more you do code reviews, the less people avoid them and vice versa. If you do a code review once a month, you will find more errors and this looks bad for the programmer. When you do frequent code reviews, you may find a couple of errors that the programmer can easily fix and it does not seem like an embarrassment. Also, the quality of code goes up with each code review (as people avoid older bugs) and they look forward to showing better quality code. The end state is that people ask for code reviews to show off their code and challenge you to find bugs.

Now, there are many tools that help you identify coding problems. My view is that it helps advanced programmers more than it does junior members. The latter need more direction and prioritization initially. Soon, they will know how to better use tools to improve their coding. Automated tools should be considered a complement to code reviews. Use them, but do not dispense with code reviews in a team setting.

An important thing to remember is that if you are doing a code review for the first time with somebody, only raise 1-2 issues so that they are more inclined to come back for more once they fix them. Comment only on the most critical problems in their code. Also keep the tone calm so that they don’t feel that they are in an inquisition. The whole idea is that they should feel that both you and them are working towards the same goal of quality in the product. It should never be about the programmer who has written the code.

Comments (15)

By Krishna, July 23, 2009

The idea of software craftsmanship is very appealing. It elevates the art of programming and sends a message that programming is a lifelong dedication to improving one’s skill and aspiring towards perfection. All that is good and noble about programming is embodied in the term “software craftsmanship”. But the history behind the term “craftsmanship” troubles me.

The idea of craftsmanship is a concept from the medieval periods about a career transition from apprentice to journeyman to master craftsman. Apprentices learn skills under a craftsman and become journeymen after the apprenticeship. Journeymen have to be accepted by the master craftsmen into their guild before they can become one themselves. I don’t think anyone takes this literally when they use the term “software craftsmanship” (though, some do), but it does differentiate between an experienced, master craftsman and the rest.

And I think this is divorced from reality. What we have seen and are seeing is that there are many software products created by young, self-taught programmers. The beauty of software innovation is that a fresh software developer can leap-frog over experienced ones by simply using newer technologies and frameworks, which are becoming more powerful every day. This is analogous to how developing countries use new technologies like cell phones to rival developed countries by shorting the process undergone by the developed nations.

This is not to belittle the knowledge of experienced programmers, but to point out that much of such knowledge has already been distilled into development tools. For example, a junior developer using Ruby on Rails, ASP.NET MVC or Spring is automatically working at a higher level of programming than she would have 10 years ago. There is still an advantage brought by experience, but it is decreasing every day.

In fact, by its nature, software craftsmanship can sometimes run counter to innovation because it values experience over experimentation. In craftsmanship, experimentation, by definition, would be under controlled circumstances under the observation of a master craftsman and is therefore limited in what it can achieve. It also emphasizes control and organization which are qualities inimical to disorganized experimentation.

I have to be careful what I am trying to say. I am not saying that there is no value in experience or learning. Quite the opposite. I am saying that the value of existing experience and knowledge is eroded by innovation so much that the experienced programmer has to work all the more harder to keep up with youngsters. Not only does the experienced developer have to learn the latest in software, but they have to unlearn many items they know.

Now, everyone is at liberty to define what they mean by “software craftsmanship”. If it simply means working to improve the quality of your code, I find no objection. I mean, who would object to better code quality (the software equivalent of motherhood and apple pie)? But if it means that you somehow become a “master craftsman” and can differentiate yourself from “apprentices” based on years of experience, it is not only an elitist view, but also an illusion. Wake up before the apprentices start running circles around you.

Comments (1)

By Krishna, July 19, 2009

Tom DeMarco has written a thoughtful and introspective article on software engineering (PDF). In that, he questions some of his early work on metrics, wondering if it is still relevant. He suggests that there was too much focus on time and budget deadlines when the more important goal should have been making great software.

strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value. To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?

DeMarco’s article can be interpreted in different ways, but I think he, like many people, is trying to reconcile how to find a balance between getting results from a software project and managing unpredictable human beings. Many software engineering principles find their inspiration from methodologies used in other engineering disciplines and industries where the “human effect” has less of an impact on project success.

Let’s take a software engineering concept like metrics. They are very useful, but they suffer from many problems:

1. Measuring something changes the behavior of the team with regard to that metric. If you measure bug count, it will decrease, but perhaps at the expense of something else that is not measured.
2. Collecting and analyzing metrics takes time and money. As DeMarco points out, controlling a software project is more useful when the marginal value is less, but if you spend money on metrics, how much ROI do you get?
3. Metrics collection affects the human relationship aspect of team dynamics. How do you balance your trust in metrics with your trust in the delivery capability of the team?

So while they provide valuable insight into the present state of the software project, they have a distorting effect. But if you throw out metrics entirely, you are flying blind with no idea about the quality or completion of the project. So there has to be a happy medium somewhere.

The problem with the formalized concept of software engineering is that it gives you the illusion of control. The project manager assumes that by following a set of processes, they will achieve the goals of the project. If there is any deviation, it has to do with not follow the methodology to the letter. Something was missed, or something was not done 100%.

We can see this at work with how people approach CMMi, Agile, PMP or any other methodology. Each has its own merits, but the implementors (project managers, PMOs, quality teams) want complete adherence to the methodology (straight or tailored) and deviations are treated as non-comformance. If a project fails, it is always a mistake of not following the principles properly.

And like DeMarco, I feel that this is wrong. No methodology can give you the whole truth. There are methods and techniques to help improve software quality and productivity. But there are never any silver bullets and we have to let go of assumptions that we can find sure-fire ways of producing perfect software. As the software field continues to innovate, we have to also innovate in ways of managing teams and producing better software.

Finally, read DeMarco’s analogy about controlling the teenager again. Many project managers and team leaders commit exactly that mistake – treating their team as a bunch of teenagers that must be controlled, measured and made conformant to a set of policies and processes to make them successful. What hubris! Why not trust them to do the right thing?

Comments (2)

By Krishna, July 18, 2009

It is now official that WordPress themes are GPL, which creates problems for the business models of the design companies which were offering “premium” themes. A few weeks before this happened, a few premium theme developers such as Revolution decided to release their themes under the GPL and Alex King called them on it to see if they really understood what the GPL meant. Going by the comments, some don’t:

I think those of use who have GPL’ed our themes are more saddened by the fact that certain individuals are completely exploiting hundreds or in my case thousands of hours worth of development time and purposely trying to use the GPL for their immediate personal/monetary gain.

The problem, though, is that the GPL is exactly meant to do that. You can take any GPL code and redistribute it for free or even sell it, the only condition being that you pass on to the recipients the same freedoms that you received. This is what the GPL Preamble states:

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users. [...]

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

The GPL is about protecting freedom, not about protecting profits or intellectual property. It also makes it easier for developers to use code (as long as they share equally) and for users to distribute code without having to worry about the fine print or royalties.

Secondly, as one of the commentators stated, the producer of a GPL product like a WordPress theme has already benefited from the work of other GPL authors:

If I were to release all of your themes for free on my site, you claimed I’d be “completely exploiting thousands of hours worth of development time and purposely trying to use the GPL for their immediate personal/monetary gain.”

How is that different than the fact that you’re using thousands of hours developing the platform of WordPress for your own monetary gain?

I suppose many people are confused by the fact that money has been made on open source products, especially the big few like mySQL, Linux and WordPress. Part of this is because the GPL made no restriction on charging for free software. In theory, selling a copyable item for free doesn’t seem viable because why would you pay for something you can get for free once the first copy has been sold?

In practice, the “code” is always “free” as in zero dollars. What you really pay for is the service and the brand behind the code even if you seem to be paying for the code. Businesses have paid for separate commercial licenses for GPL products to avoid legal problems. But some assume that you can make money by simply selling GPL products, but without any service offering, that is a risky business strategy.

This kind of attitude is not restricted to the GPL. Seth Godin had a similar confusion sometime back about the Creative Commons license he was using. To his credit, he updated his post to clarify his intent, though it would have been better served if he had changed the title heading and deleted what he had written.

This is all very ironic. Many people seem to use the copyleft licenses because it apparently is cool, like supporting environmental causes, to have your code or work published under an open source license. Or they wish to benefit from the open source community. In other words, they use open source because they gain something. But God forbid, if someone else gained something by taking advantage of what the license allows them to do.

To end these double standards, people need to educate themselves about software licensing and intellectual property rights. If they cannot tolerate the freedoms that the GPL or Creative Commons gives to their users, they have the right not to use those licenses. They have the full freedom to write or pick a tighter license that explictly states what they allow. Using plain old copyright is simple enough. Or hire a lawyer.

Comments (2)

By Krishna, July 16, 2009

I was amused to read the story of how somebody from Apple wanted Microsoft to stop the Laptop Hunter ads. Because last week, I was with my friend providing moral support while he was hunting for a laptop at BestBuy. Yes, he bought a Windows laptop, though not for cost – he needed a PC to do some of his development work. There were a few Apple laptops also on display and that started a conversation on our way back.

While at BestBuy, I noticed that the most expensive Windows-based laptop that they had was priced at $1099 – maybe there were more expensive models, but I missed them. I remembered the Laptop Hunter ads and told my friend that someone shopping on price alone would always choose a Windows laptop. For the time being, I am ignoring those who need a particular operating system for a specific functionality. Many people who buy computers are not familiar with the technical details and so may be more influenced by price.

So here was my argument:

Suppose a person walks into an Apple store and BestBuy store. In each place, they see many laptops at different prices. The normal customer wants something mid-range. They don’t want the cheapest computer because it probably sucks. The highest priced computer is a luxury item. So they would like to choose something in the middle. This is the behavior you see with most consumer items. When you buy a TV, you are most likely not to buy the cheapest or most expensive TV, but rather a price point in between that gives you the biggest bang for your buck.

So if you go into an Apple store, you get a MacBook for $999 and your MacBook Pro goes all the way from $1,199 upto $2,499. The mid-point seems to be around the $1,500 range. In contrast, the price range in BestBuy runs from $450 to $1,099 (as far as I remember) and so that is roughly $750. So the comparison between the mid-point prices gives the appearance that an Apple laptop is twice as costly as a Windows one. Worse, the most expensive Windows laptop is $400 less than an Apple.

Obviously, if someone wants a Mac or wants a PC for reasons other than price, they will know better. But what about the lay person who is probably buying a laptop to send email and write documents?

My friend didn’t agree with me and here was his argument:

It is all about branding. I would rather have the cheapest Apple laptop because there is the pride of ownership. You can show off your Mac which you cannot do with a Windows-based laptop. Think of Windows as a line of Toyota cars and Apple as a line of BMWs. You would rather have the cheapest BMW than the best Toyota.

Most high-school and college students beg their parents to get them an Apple because it is way cooler than a PC. The college student would rather get the lowly MacBook because in the end, it is an Apple.

He has a point. But I wonder how much of an effect brand has, when taking the price difference into consideration. I don’t mean that rhetorically – I am asking a question. How many customers does Apple lose because of its price structure and how many does it gain because of its brand? In fact, Apple cannot cut its prices to match Windows because it could affect the branding (If Apple costs the same, what is the difference?).

If the Microsoft executive is telling the truth, it suggests that perhaps the ads are hurting Apple in a measurable way, and  the price premium for Apple is above the brand effect.

Comments (0)

By Krishna, July 15, 2009

While conducting interviews, I keep running into programmers who seem to be very specialized, but know little outside that zone, even if that knowledge is very related to their work. That is, they know a programming language and framework and they can program all day in that, but they are not very knowledgeable in databases, web servers and so on. And this makes them less useful in many situations.

Now, I understand that learning even one language or framework can take significant time and it is better to stay focused than be all over the map. And from a career perspective, it is useful to point out continuous experience in something than experience that is distributed across multiple knowledge areas. As a general principle, that is valid, but in practical terms, a software developer is very inefficient if they don’t know more about knowledge areas that directly affect their work.

Let me give a few examples:

1. Someone who only works in the middle tier (business layer and data layer) and knows nothing about web design (HTML, CSS, JavaScript).
2. Someone who only uses an ORM to connect to the database and does not know how to write a SQL query, does not understand database design. Or worse, always relies on a database admin/developer to write SQL queries for them.
3. Someone who doesn’t know to install their web server or configure its settings.
4. Someone who doesn’t understand security concerns such as SQL injection, authentication, etc.

A team comprised of specialized personnel (pure web designer, pure developer, pure DBA) may produce results. But there will be more bottlenecks when compared to a team that has people who can contribute at each level if required. This does not mean that each person will do everything (practicing “total programming”!), but they can reach out of their comfort zone to get things done.

Yes, some companies institutionalize these silos by creating departments with various functions. Risk management and bureaucracy does the rest. But that is no excuse for individuals not to extend their learning outside their primary job functions. For acquiring knowledge at the basic level I am talking about, it would hardly take 10 minutes a day on a consistent basis.

Comments (0)

By Krishna, July 12, 2009

Bruce Eckel, one of my favorite book authors, has a thinly disguised anti-Microsoft screed titled “The Cathedral and the Pirate” with Google Chrome OS used as a bludgeon. Apparently, Microsoft is a cathedral and Google is the pirate which can run rings around the cathedral – oops, mixed metaphor – galleons. Eckel also compares Microsoft to a water buffalo and a net in the jungle which he is at it.

There are many areas where Eckel goes wrong, but let me point out a few. For example, he says:

you could take a bigger risk and redefine the playing field by creating your own browser, and then implement the most advanced technologies, correctly, or at least the way you want them. At some point — you’ve got enough clout, after all — you can start saying “this application will only run properly under Google Chrome.” And for that matter, you can start shipping Chrome with all the necessary support for offline storage and connection to the operating system services required to create more sophisticated apps. “Developers, developers, developers!” will soon start creating their own apps that will only run under Chrome, just because it’s the easiest path (they already know JavaScript, but now it works without pain and they have access to storage and other OS things, but sandboxed so they don’t have to worry about viruses and other corruption).

If I remember my history of browsers correctly, Internet Explorer was in the situation where they owned 90% of the browser market. Many web and application developers only tested against IE because it was not worth testing against Netscape or other browsers. But Firefox came with better features and slowly eroded IE’s advantage. Why should Google Chrome be any different?

Any feature (including offline storage) implemented by Google Chrome will be copied by other browsers, especially Firefox, but also IE and Safari. Why should people switch to Chrome then? The non-Microsoft crowd is already invested heavily in Firefox, so there is limited scope for growth for Chrome.

Eckel raises the specter of viruses quite often in his article, but they are mostly strawmen. He says that his brother spends half his time cleaning up virus-infected systems in small and medium businesses. But could those businesses switch to netbooks? A better answer would be to move to Linux or Mac OSX systems. This argument also ignores the strides Windows has made in terms of security and how much people pay attention to security when they buy systems.

Microsoft is targeting netbooks with Windows 7 Starter edition that will probably have lower OEM prices. The extra cost that Windows (or any other standard OS) adds to netbooks is more than offset by allowing them to run different applications. Unless Google Chrome OS has a version of every desktop application that can run on Chrome, the price argument is a non-starter.

Netbooks is a high-risk, low-margin market segment that is under attack from two sides (cell phones and laptops). And Google Chrome OS faces the same risk. Laptops, as desktop replacements, need full-fledged OSes. So the best bet for Google is Android because here it can credibly compete with the other mobile OSes.

As for Microsoft, yes, its margins will decline with decreasing costs of hardware, but Windows will stay around for a long time. That, however, will be a topic for a future post.

Comments (8)

By Krishna, July 11, 2009

Farhad Manjoo of Slate takes down the upcoming Google Chrome OS:

But here’s the crucial sticking point for Chrome: Because it’s based on a Web browser, every app developed for Chrome will also run perfectly on Windows or the Mac. By definition, then, Microsoft and Apple machines will always be able to do more than Chrome machines—they’ll be able to run Web apps and the processor-intensive desktop programs that we’ll still need in our glorious Webby future: movie-editing software and CAD programs, for instance. [...]

This is what Google said:

For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.

If all the Google Chrome OS apps can run on other operating systems, you would want a Google Chrome-OS machine if

• You only want/need to use web applications.
• You are very price-sensitive.

I am not even sure if the latter applies, because presumably you could replicate Google Chrome OS by using a Firefox+Linux installation at the same cost. Why would netbook companies even use Google Chrome? Is Google paying partners to install Google Chrome OS on their netbooks, a reverse OEM licensing situation. Manjoo blasts Google’s business sense:

If 20 percent of the world’s computer users switched from Windows to Chrome, would that help Google’s bottom line? Sure, all those people would now be using Gmail and Google Docs—but they could have been doing that in Windows, too! An MBA might describe the Chrome OS as a wasteful customer acquisition expense; Google would be wiser to use all the cash that it’s pouring into developing the new program for advertising instead. But a gangster would call this move what it really is: The point of Chrome OS—the only point of Chrome OS—is to screw with Microsoft.

In fact, the whole concept of netbooks seems weird to me. Cell phones are becoming so powerful these days that for most tasks done on the go, you don’t need anything else. You can find laptops that are light and thin enough to carry around with you without being a burden. Wireless broadband cards enable you to access the Internet from different systems instead of being tied down to one machine.

Netbooks, by definition, occupy a place between cell phones and laptops. And therefore, they will be squeezed by ever-increasing functionality of the former and ever-increasing price declines of the latter. Secondly, the type of person that needs a netbook is a person who also needs a powerful cell phone and a laptop. So far from being a replacement for anything, a netbook would be an additional device, further reducing its reach.

Now, the share of netbooks in all laptops jumped from 1% to 19% in 2008. But apparently, that seems to include netbooks that are very close to being called laptops if it weren’t for their size. In any case, the type of netbooks that Google Chrome OS would serve is a niche within netbooks where, if I understand correctly, no local application other than Google Chrome would run.

Google, of all Microsoft competitors, has the best chance to supplant Windows with a different operating system. Google Chrome is a fantastic browser – I am using it now as my default browser. Yet, I cannot see this as a real game-changer unlike people like Paul Thurrott. I would think that Android has a much better chance to become big in the long run.

Comments (0)

By Krishna, July 10, 2009

I was reading Ryan’s post on WolframAlpha when I realized that this was the first time in weeks that I have thought about WolframAlpha. There was a big burst of PR during its release  - the mainstream media, the technology blogs and so on. After that, I never heard anything about it. Of course, the recent search engine news has all been about Bing. Maybe that is one reason.

For software practitioners like you and me, we focus too much on the software part of the product lifecycle – the architecture, design, coding and testing. But there is a whole another world out there, where you have to get real users to like and use your product. Otherwise, it will end up unused and finally discarded.

However useful the product is to end users, you have to invest significant amount of time in marketing. And the term “marketing” is not as simple as it sounds. It is not about a big TV spot or full-page newspaper ad. It is informing, attracting and keeping users through many channels, including the fore-mentioned TV and newspapers, but also through building references, communities, and partnerships.

Product improvement is also a huge part of the marketing process. If you start with a few users, how do you maintain their interest and keep them coming back? How do you improve the conversion rate of users who visit your website and do not sign up? How do you cater to users who are looking for more?

So, there is no endpoint for the development effort. You can create a plan for development and complete the features. But the story doesn’t end there, because you have to continue to put the effort, even if it is simply to upgrade and scale the application. This means you have to produce on a regular basis. If you opt for a big-bang approach of finishing a ton of features, users will simply leave you behind.

Comments (0)

By Krishna, July 9, 2009

A project operates most efficiently when the division of labor within the project is done effectively. In simple terms, this means

1. Every person works on tasks that will maximize the benefit to the team.
2. Even if they are good at other tasks, they focus on tasks that bring the greatest value.
3. They delegate those other tasks to people who could do them less expensively.

For example, even though the software architect in your company could be the best coder in the company, you don’t want her to sit all day long writing HTML code. Her talents are better used in design and architecture. So although there are several things she could do better than anyone else, she is used in the tasks that bring the greatest benefit to the organization.

Unfortunately, at an individual level, many miss this point. They spend their time being busy in tasks that could be easily delegated to someone else. Usually, the reason given is that they are the best at that particular task and/or if they give the task to others, it would not be done perfectly.

In reality, this results in a huge opportunity loss. By taking on such mundane tasks, the person is unable to spend time on more value-added jobs that has greater benefit to the project and organization.

Most people do this because they are scared of failure. What if the delegated-to person messes up the task? In my view, that is only a valid excuse if there is very little room for failure. For example, if you (as a manager) have to make a presentation to a big prospective client tomorrow, it is not a good idea to simply rely on a tester – you probably should do some smoke testing yourself.

On the other hand, in many situations, you have the ability to tolerate some failures and have time to train people. And that is where you should start delegating tasks. Yes, there will be mistakes, but you can point that out. If you have a person who has the ability to learn from their mistakes and follow processes, things will get better over time.