Eitan Suez's Blog

Thoughts on Gosling's "Sharpen the Axe: the Dark Side"

I am very grateful to James Gosling for posting his blog entry of January 4, 2005: "Sharpen the Axe: the Dark Side." (http://weblogs.java.net/jag/)

The reason is that I believe this very topic to be of utmost importance to software developers (and their employers!). The second reason is that I don't believe this issue is discussed openly enough. So, first of all, thank you Dr. Gosling for the post.

Software development is a relatively young industry. We're still trying to figure out the right recipe for a successful software project.

I believe that many developers go through a nerve-racking decision making process at the start of every new project. The success of the project hangs in the balance.

An evaluation process goes on in developers' minds: how much work is this project going to require? What resources (people, budget, time) are at my disposal?

We all know time is a very precious resource on software projects. We've also learned that adding more developers (beyond n) to a project does not necessarily imply increases in productivity.

My guess is that more often than not the situation is one where the amount of effort is far greater than the available resources to complete it. That is, to use the analogy of sharpening the Axe:

When a developer is asked to cut down an entire forest by himself, how much good will sharpening the Axe do?

Sure, there's a tradeoff: if we spend the time to sharpen the axe, we are taking time away from cutting down trees. And the promise is that we will make up the time by cutting much faster with a sharp axe.

However, in this case, neither solution will work! There's no way we'll cut down the entire forest; and the project will fail. All the developers know it. Management and the marketing department is in the dark. They have no clue.

What we need to do is invent a chainsaw, and quickly! So in this extreme (yet possibly prevalent!) case, it doesn't matter what decision we make. Or does it?

I believe it does. Here are my reasons: the problems are not going to go away. The need for the chainsaw will always be there. So we might as well start working on it.

The problem is that there is no reason on earth why the company you work for (maybe an insurance company, a hospital, or an accounting firm) should stray so far from its core business to support the development of a supposed revolution in software. In these environments, developers are faced with shorter-term pressures.

What about companies that are in the business of building software? What about IBM, Microsoft, Borland, BEA, Sun? You've got me there; I have no clue. I've never worked for large software companies. I can only offer hypotheses: maybe developers at such companies are not directly exposed to customer needs, the way IT departments or consulting firms are? So this problem may not be in their radar. Surely it's in IBM's radar?

a. they're a huge company with lots of resources
b. they not only develop software but they have a huge consulting services arm

Conspiracy theorists might hypothesize that if they did come up with a solution, then from a business perspective the solution would no longer necessitate the huge charges of software consulting services. The problems would go away and so would entire software consulting industries. One must admit there is some truth to this rationale.

So who's working on a chainsaw these days? And how does open-source play into this? I want to hear your opinions.

Comments

• When it comes to software development productivity tools, I definitely consider the project I lead here to be a chainsaw. I believe the free and open source software communities share a special distinction in that they are logically immune from any productivity tool conspiracy theories . F/OSS project developers receive candid unfiltered feedback, directly from the developer community, which may not be the case with proprietary tool companies.

  There is also another analogy that I think fits here. Even if there is not yet the necessary software chainsaw; a job may well be impossible for a small hired crew, but it may not be for a large group of volunteers. As the old saying goes: Many hands make light work.

  Posted by: cajo on January 17, 2005 at 02:21 PM

• I also wrote a response to Jame's blog entry, comparing to agile principles:

  Taking the Bullet

  Posted by: jhook on January 17, 2005 at 03:23 PM

• What about companies that are in the business of building software? [...] So who's working on a chainsaw these days?

  I currently have an internship at SAP. Other departments work on a chainsaw, the Netweaver IDE. We get to make requirements and suggestions for it, and sometimes we also get to meet and talk to them directly. From my department, one developer is going to be "leased" to the Netweaver IDE department for a couple of months to improve IDE performance, which has been a real problem for our department.

  Posted by: monika_krug on January 18, 2005 at 03:58 AM

• cajo, thank you for the right-on-target comments. i'll need to take a closer look at the cajo project.

  jhook, i enjoyed reading Taking the Bullet. thanks for pointing me to your blog entry.

  monika, thank you for sharing some of the work that is going on at SAP.

  Posted by: eitan on January 18, 2005 at 07:09 AM

• I remember somebody (Rob Gingell?) at the top of the Sun/Java pyramid several years ago said something along the lines of "don't just develop an application, develop an API". At the time I was on a new contract faced with a discrete set of requirements that I could have met with brute force, but I strapped it on and chose the path of extensibility and elegance because I wanted to solve the problems of tomorrow in an exciting new space. It was definitely some extra work, but the results went over so well that I got additional contracts on the merits of the effort. Trouble was, as I spent time in the interim working my chainsaw in my own thick forests, I found many deficiencies that had me concluding the need for a ground-up redesign, which I eventually did. I don't have a guess what the median number of iterations would be to get a powerful solution right (enough), but my conclusion from this experience is that it's unreasonable to expect something sophisticated to be a one cycle affair. Instead, I would say the great solution will always take longer than you think and repeat that aphorism "you always through one away". On the other hand, I find the power solution to be incomparably gratifying, and I'm definitely up for round two.

  Posted by: mentata on January 18, 2005 at 03:54 PM

• Often I see poor management as the culprit for lack of resources or even vision for the project. That will continue as long as business sees computers as "easy"

  Posted by: smartinumcp on January 19, 2005 at 06:41 AM

• Personally I think a chainsaw could not be built until the forest has been mapped out.

  As with any new technology the services that the tool would need to provide would be unknown at the time of development. But as the technology grew the tools would slowly develope into "chainsaws".

  How would anyone know what kind of trees the entire forest is consists of, unless some exploration has taken place.

  So, tool development just take time. Or maybe we should look at an industry that is not so young. Hardware design, or maybe something older like resturants and cooking.

  Posted by: bigmike_triand on January 19, 2005 at 08:20 AM

This work is licensed under a Creative Commons License.