Constant Random Change

For anyone who has experienced working in a corporate environment, reading books about 21st century management can be really depressing. Rapid Development made me feel really down (especially since it was just lying there in the office bookshelf with no managers or senior developers reading it), but it wasn’t as bad as The Essential Drucker: that book affected me so much that at one point I closed the book and didn’t touch it until I felt better.

Here’s an excerpt from Peopleware, another book on managing software teams, discussing something about productivity. See if it could make you put your face in your hands and groan:

Historians long ago formed an abstraction about different theories of value: The Spanish Theory, for one, held that only a fixed amount of value existed on earth, and therefore the path to the accumulation of wealth was to learn to extract it more efficiently from the soil or from people’s backs. Then there was the English Theory that held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spanish spun their wheels trying to exploit the land and the Indians in the New World. They moved huge quantities of gold across the ocean, and all they got for their effort was enormous inflation (too much gold money chasing too few usable goods).

The Spanish Theory of Value is alive and well among managers everywhere. You see that whenever they talk about productivity. Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.

That’s not exactly productivity—it’s more like fraud—but it’s the state of the art for many American managers. They bully and cajole their people into long hours. They impress upon them how important the delivery date is (even though it may be totally arbitrary; the world isn’t going to stop just because a project completes a month late). They trick them into accepting hopelessly tight schedules, shame them into sacrificing any and all to meet the deadline, and do anything to get them to work longer and harder.

Being unemployed, I finally have the chance to go to the Philippine Youth Congress in Information Technology (Y4iT) this year.

With the event less than two weeks away, I’ve decided to plan out what I’ll be doing in those four days. Given that the talks will be done simultaneously at the UP Theater and the UP Film Center, I have to decide which talks to attend.

My choices under the cut.

Continue reading »

Refactoring is a term you’ll hear thrown around a lot in software engineering discussions. If you’re unfamiliar with the term, you might assume based solely on the content of those discussions that it’s a mystical advanced programming technique known only to experienced developers.

But what exactly is refactoring?

Continue reading »

Let’s face it, everyone fails at software estimation including yours truly. It’s probably the least understood part of software development simply because the uncertainties in

This post will not deal with software estimation directly. Instead, it will show you the graphs related to software estimation that you should be familiar with. All of these graphs come from Steve McConnell’s wonderful book Software Estimation: Demystifying the Black Art; the first group of graphs were copy-pasted from the free Construx presentations while the rest of the graphs were drafted using MS Paint.

Continue reading »

While I was going through Rapid Development looking for the backhoe story for the previous post, I came across the graph above.

Looks familiar, huh?

It’s practically the same productivity-to-time graph as the one in the Satir Change Model.

Continue reading »

No Silver Bullet tells us to be skeptical about claims of tools that can provide drastic improvements in productivity. What we can instead hope for from productivity tools are minor, yet still significant, improvements.

However, both lowering our expectations and going with proven technologies aren’t enough to receive productivity benefits when introducing a new tool. Many companies still fail because of a certain classic mistake: Lack of Training.

Continue reading »

Aside from Brooks’s Law, Fred Brooks is also famous for another so-called “law” in software engineering: the No Silver Bullet argument.

There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.

Continue reading »

Last night when I was sucked into browsing TV Tropes, I came across one of the classic debates in the Internet: Subbing vs. Dubbing.

I particularly like this debate not only because it’s pretty easy to win at, it’s also a great opportunity to educate people about the so-called “anime subculture”.

My modus operandi was simple: I choose to defend dubbing in the face of hordes of rabid anime fans.

Continue reading »