The newest addition to Rootless Root:
On one occasion, as Master Foo was traveling to a conference with a few of his senior disciples, he was accosted by a hardware designer.
The hardware designer said: “It is rumored that you are a great programmer. How many lines of code do you write per year?”
Master Foo replied with a question: “How many square inches of silicon do you lay out per year?”
“Why…we hardware designers never measure our work in that way,” the man said.
“And why not?” Master Foo inquired.
“If we did so,” the hardware designer replied, “we would be tempted to design chips so large that they cannot be fabricated – and, if they were fabricated, their overwhelming complexity would make it be impossible to generate proper test vectors for them.”
Master Foo smiled, and bowed to the hardware designer.
In that moment, the hardware designer achieved enlightenment.
Possible tag failure there.
>Possible tag failure there.
Flipped myself into a “Visual” editing mode I hadn’t noticed was there…fixed now.
Nice. Reminds me of the suckless.org philosophy.
>Flipped myself into a “Visual” editing mode I hadn’t noticed was there
Are you experimenting with Vim (or, more probably, with Evil)?
>Are you experimenting with Vim (or, more probably, with Evil
No. It’s a WordPress editing mode invoked by an inconspicuous tab on the upper right hand corner of the main text box. I think it may be a recently-added feature.
>No. It’s a WorPress editing mode…
Yeah, it was a stupid thing to ask. My bad.
>I think it may be a recently-added feature.
Speaking of which: lately, I’m noticing a link to your Google+ page at the end of each of your blog entries. Is that the intended behavior?
>Speaking of which: lately, I’m noticing a link to your Google+ page at the end of each of your blog entries. Is that the intended behavior?
Yes, WordPress has an option to generate that now which I just switched on.
I am deeply surprised, given the age of this koan, that it wasn’t added long ago.
The visual editor has been a feature for awhile. There’s a setting in the General Settings screen that can switch off visual editor. If you’ve been doing a database scrub, some of your settings may have been reset to the defaults.
That’s a good one.
The corollary of this koan is that the best performing member of a development team is the one who removes most code lines.
I can totally see that.
I did some technical writing once. I quickly found that manager-types valued page count more than appropriate, concise instruction.
Rather than obfuscate, I added a ridiculously detailed and unncessary index, a useless glossary, widened the margins, and went to a larger font. Finally the managers felt that they were getting their money’s worth.
I know you’re a serious Emacs user so I’m wondering why you’re not using
org2bloginstead of the native WordPress editor. Being able to write and publish your blog posts from the comfort of Emacs is a real win IMHO.Actually the setting for visual editor is in the User Profile screen.
> I quickly found that manager types valued page count more than appropriate, concise instruction …
I think the best choice there is to add extra stuff that is nicely self-contained and that perceptive readers will be strongly encouraged to ignore entirely. Lots of examples, extra explanations, diagrams, etc. But if you were going for minimal effort, I can understand that as well.
We don’t get such choices often with software because every addition is a big maintainance burden too. Even comments must be kept up to date with the rest of the code. The only obvious win AFAICS is using doxygen-like systems to generate user documentation from code comments.
Indeed. I thought about exactly that when you used the word “featurectomy” in your post about your gpsd bug.
You know you are a real programmer ™ when you proudly report to someone that your productivity today was negative one thousand lines of code.
>You know you are a real programmer ™ when you proudly report to someone that your productivity today was negative one thousand lines of code.
Heh. Cat-v.org quotes Ken Thompson as saying something very similar.
And let’s not forget the old saying, “Less is more”.
Managers favor objective measurements of productivity. Concise, appropriate instruction is hard to measure. Page counts aren’t.
@Jorge
I had a look at the link you mentioned. There are some gems in there. This is my favorite from the inventor of quicksort:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.”
Gotta love that dry British sense of humor…
@Jay
You are right managers need objective measures. LOC is a very bad measure that also happens to be objective. However, there are other objective measures that are useful. For example progress on a burn down chart, and/or number and severity of defects. LOC is a lazy objective measurement from bean counters. That doesn’t mean that objective measures aren’t possible.
Well, I was referring mor to the tech writer’s page count…
@Jessica Boxer e.a.
In Academia the bureaucrats started out counting pages in publications. When that was gamed, they went to counting publications, then citations, then journal impact factors, and now H indexes.
I do not believe there are objective measures of quality in intellectual work. How to compare books objectively? Works of art? Design?
In the end you need people judging quality. Counting citations is a form of crowd-sourcing quality judgements: You trust that those who cite a paper, found it valuable.
Now, how could we organize a crowd-sourcing of code quality?
While I think that’s incorrect, it’s neither here nor there when discussing code, which is more engineering than self-expression. An experienced programmer can estimate relatively about how much effort a particular feature will take (the idea behind story points), the needed tasks can be ranked by business importance (a backlog), and the pace of the developers at fulfilling those needs measured.
Similarly, the quality of what’s produced has some objective metrics, such as test coverage and “smelly” idioms (e.g., per Coverity) that can give some real insight as to the likelihood of problems with it.
@Christopher Smith
“An experienced programmer can estimate relatively about how much effort a particular feature will take (the idea behind story points), the needed tasks can be ranked by business importance (a backlog), and the pace of the developers at fulfilling those needs measured.”
That is true about positive feature completeness. When building a banking application, you list the features and cryptography and tabulate progress in implementing these. That is fine. But I would guess that would mostly involve human judgment in some form.
But how to tabulate code robustness and manageability? And security against sentient opponents?
How about the quality of work removing features that would impair usability and security?
@Winter
> That is true about positive feature completeness.
The problems with most metrics used by program managers is that they try to measure parametrically, such as with LOC or function points, when they should be measuring the actual outcome they want.
For the most part what a software development effort is supposed to produce is software with a certain set of features at a certain bug level. Both of these can be measured pretty directly. Using an agile approach, which is to say frequent sprints with fixed delivery dates in the order of weeks rather than months, makes both these things relatively easy to measure without iceberg problems. (By which I mean creating a GUI makes software look finished even if there is still 90% of the hidden back end to do.) Agile requires top to bottom vertical integration of sliced feature sets.
Bug counts are a little less reliable since they are very dependent on the quality of the testers. However, there are a number of objective measures that can analyze this, user story coverage (if you use user stories, which I don’t) or code coverage being good examples.
> But how to tabulate code robustness and manageability? And security against sentient opponents?
All these things can be measured. There are, for example, tools that can measure code complexity which is a pretty good proxy for robustness and manageability, and good testing measures this too (code coverage on all that error testing in the code is an indication of this.) As to security, again there are a few tools to help measure this too, and I suppose there might be an argument for a specialized set of testing using some of these sentients to make that determination.
> How about the quality of work removing features that would impair usability and security?
As to the former, this is based on the up front judgement of the sponsors of the code. They get to decide this. It is rare in my experience that people take features out, though I agree that they should. As to security? Not sure about that.
> they should be measuring the actual outcome they want.
Back in the ancient times of “top-down programming” that was easy. You had an overall spec that unfolded like an outline, with gazintas and gazoutas and module listings, each with a test procedure. When each part was finished, you just ticked it off the master list. You knew what you were building, and you knew when it was finished.
(well, at least in the idealized past, seen through rose-colored contact lenses…)
The problems I kept running into in the real world was that employers often didn’t know what they wanted, didn’t want what was delivered, and wanted to keep changing things forever. I had a few customers get angry when I told them they’d need to negotiate a new contract for additional features… In corporate employment I didn’t have that option, and it’s rather hard to know much progress you’re making when the goalposts change every few hours…
The concept is well-known and resonates.
But any (good) hardware designer already knows this as well as any (good) software designer without having to learn it from a software dude, so that part doesn’t really resonate.
Also, the “How many square inches of silicon do you lay out per year? / We never measure our work that way” exchange fails in a couple of ways: (1) silicon area is, in fact a significant metric, because for commodity parts, die cost is a huge portion of the cost of a chip. So, while we don’t use that metric for productivity, we do, in fact, “measure our work that way” for other extremely pragmatic reasons; and (2) in any case, square inches would not be the preferred unit. As a recent example, for a chip we laid out last year, if you divided the area by the number of people who worked on it, you probably get around 0.0007 sq in per designer per year…
Finally, I will say that all other things being equal, LOC is actually not a bad metric for utility. It is not incorrect to say that all other things are not equal, but OTOH I would argue that for modules in well-maintained open-source projects (especially those with good unit tests and continuous integration), the trend line for all other things heads towards equal.
On a completely unrelated topic, is it just me who thinks that “yes means yes” is a particularly Orwellian way to describe a bill that states Affirmative consent must be ongoing throughout a sexual activity and can be revoked at any time. ???
>1) silicon area is, in fact a significant metric, because for commodity parts, die cost is a huge portion of the cost of a chip. So, while we don’t use that metric for productivity, we do, in fact, “measure our work that way” for other extremely pragmatic reasons; and (2) in any case, square inches would not be the preferred unit.
Damn. I wanted to avoid the word “productivity” there for stylistic reason, but it looks like I can’t.
I’m not concerned about (2). Mildly inappropriate use of archaic units adds to the humor.
> Well-maintained, open source modules
The problem with that is a metric of maintinance and code quality would need to be found, as a large well-maintained module can have as many LOCs as a smaller module with lots of cruft hanging on to it.
Hypothesis: LOC=functionality/maintainance , or something
Jay
>Managers favor objective measurements of productivity.
OK, this is exactly what I don’t understand about most programming blogs and discussions on such blogs. Maybe you could enlighten me? The point is: how comes apparently everybody is working or has been working for companies large enough to have managers and organized enough to actually _measure_ productivity, instead of just basically hiring people they like and firing people that simply don’t fit?
All my life, and most of my friends too, have worked in companies employing about 10-15 people. It varied between 2 to 45 employees. It was either about customizing something (SAP, Navision, Oracle, whatever), or custom-building stuff like web shops. Occasionally, they made a product but it was typically that would sell a few large copies heavily customized (again, like a webshop), not something that would sell a million copies in shrinkwrap. The owner was the manager and was also the salesman, spending 90% of time trying to sell, means, having little time to manage. Programmers were more or less on their own. Productivity was not measured because there was no room for promotions anyway as it was too small to have a hierarchy, and cold, objective judgements of people would have upset the jovial, familial mood in them. Salaries were typically fixed maybe with some boni tied to the firms overall profitability, hiring was based on being liked by / impressing the owner, and firing didn’t quite happen as such, rather, people who were a poor fit have sensed the negative mood of the team towards themselves during the probation period and basically it was mutually agreed that they should rather work elsewhere. People who were a good fit would only be fired if low sales required lay-offs, even in those cases it was encouraged that some people who are not really happy or have other options should volunteer to quit. When I worked in the UK word was that every team should be reduced by one person, I volunteered to quit because I was intending to move back to Central Europe sooner or later anyway, and everybody else felt relieved as they had mortgages and stuff. My point is, in these companies there was little point in trying to measure performance or generally to make things official instead of informal and personal.
Yet, when I read programming blogs it feels like nobody ever is working for firms like that, it feels like everybody is working at Oracle and suchlike, where everything is bureucratic and official.
I am not sure why. My best hypothesis is that programming blogs are inhabited by people on the bleeding technological edge and they tend to to work for large, more or less Silicon Valley type organizations.
@Shenpen:
That is the crux of a large proportion of Paul Graham’s writings. He argues that software startups are the least Dilbertesque software companies.
@Lambert IMHO startups are different from what I wrote. They dream of becoming big, and they dream of making a product that will be used by millions of people. Which means they dream of becoming Dilbertesque, sooner or later, although it is not admitted – most likely that that point the founders will sell their shares, quit, and start another one. Startups do want to become big, and this is means the Dilbertesque part is just a factor of success and time.
What I wrote about is businesses that don’t dream about getting big, because they don’t dream about making products used by millions. Typically they code as a service, not as a product – customizing large ERP packages or custom-building webshops and suchlike. Or if they make a product, iti is going to be organizational software, that is implemented, like a CRM, with lot of customization, not something that individual persons buy or sign up to and use. They are typcially not consumer software. This is typically not very scalable, this is no way to become big.
Yes!! Finally, Master Foo is back. More of Master Foo please ESR.