Category — programming

Or so Ted Dziuba says:

Google uses C++, which is sure to attract a top-notch engineer whose only way to express his masculinity is the speed with which he can ace an academic recursive programming problem and the condescending modesty he has while explaining the solution.

Jerry Yang – Slugworth to Google’s Willy Wonka • The Register

I have a very different model of how innovation, at least in software, actually works. One of its premises can be expressed by what I shall now dub the Iron Law of Software R&D: If you are a programmer developing innovative software, the odds that you will be permitted to finish it and it will actually be deplayed are, other things being equal, inversely proportional to the product of your depth of innovation and your job security.

That is, the cushier your corporate sinecure is, the less likely it is that you will make a difference. The more innovative your software is, the less likely it is that you will actually be supported all the way to deployment.

The reason for this is dead simple. Corporations exist to mitigate investment risk. The large and more stable a corporation is, the more resistant it is to disruption in its practices and business model including the unavoidable short-term disruptions from what might be long-term innovative gain. Net-present-value accounting therefore almost always leads to the conclusion that innovation is a mistake.

esr – Open Source — Can It Innovate?

Of all the cruel tricks in software engineering, this has to be the cruelest. Most of us entered this field because the machines are so much more logical than people. And yet, even when you're writing code explicitly intended for the machine, you're still writing. For other people. Fallible, flawed, distracted human beings just like you. And that's the truly difficult part.

Coding Horror: Coding: It’s Just Writing

Because the world, full of competitors and networked humans with their set of behavior patterns, is part of the spec. If you're designing a product, but don't understand how the system of networked humans will work around it, you really can't understand how your product will work either.

How to Ship Code and Influence People (Skrentablog).

In a comment a while ago, David wanted to know why are Singletons the root of all evil. Well, that’s just because they are!

Ok, it is not that easy. Nor that black-and-white, either. Let’s see if I can articulate some of the reasons why Singletons are bad for you and for your code.

From all the varieties of pattern abuse out there, singletonitis is the most irritating one because of two simple reasons:

1. Singleton is one of the patterns with the worst side effects.
2. Singleton abuse is one of the most widespread varieties of pattern abuse.

In 99% of Singleton occurrences, the Singleton pattern was unnecessarily introduced with one of the following excuses:

• Some object needs to access a resource that isn’t available in that abstraction layer. The right solution to this problem is to redesign. Solving bad design by throwing a pattern at it just makes things worse.
• As a glorified global variable. Global variables can be avoided most of the time, and they should be avoided wherever possible. See previous point on solving bad design by layering patterns on top.
• Premature optimization (“we shouldn’t instantiate this more than once, or it will bring down performance; let’s singletonize it!”). Thousands of wise words have been written on the evils of premature optimization, so I won’t go into that here.

So it all boils down to the following: in most cases, programmers introduce Singletons either as a misguided attempt to improve a bad design, or as a means for premature optimization.

Singletons not only have the noxious effect of obscuring how objects collaborate, but they also hamper dependency injection, which in turn makes testing and refactoring extremely difficult. Thus, Singletons lead you into a spiral of unmaintainability. To think that they were unnecessary in the first place!

Apple Insider has published a detailed, enlightening and simply beautiful history of the Mac OS System Preferences panel, Road to Mac OS X Leopard: System Preferences.

The brief mention and screengrab of the NeXTSTEP Display Preferences panel almost made me reach for a Linux workstation to run WindowMaker on. Almost.

(via SwissMiss)

[Originally posted on what used to be a separate blog 'On jobs, work and careers' and later was merged into this blog.]

Interesting links on the topic of jobs, work and careers:

• Enrique Dans: ¿Alguien ha visto un programador? (Has somebody seen a programmer?):
  

  En España, a este lado del túnel, se necesitan programadores. Y los programadores necesitan una reivindicación urgente de su profesión, que recupere el legítimo orgullo de quien crea, de quien desarrolla, de quien se responsabiliza de un todo, de quien se enamora de un proyecto y no se limita a ser un obrero en el mismo, sino un verdadero arquitecto. Se buscan programadores con orgullo y capacidad para serlo. Pero por lo que se ve, habrá que mirar debajo de las piedras.

  Rough translation:

  In Spain, on this side of the tunnel, we need programmers. And programmers urgently need to claim back their profession, they need to recover the legitimate pride of someone who creates, develops and is responsible for a whole, of someone who falls in love with a project and doesn’t limit himself to being a mere labourer on it, but is a real architect. We need proud programmers and programmers with the skills to be one. It seems they will be hard to find.

• The Business of Software Wiki (from Joel on Software):
  

  Our goal is to gather and present unbiased, useful and up-to-date information about the business of software, whether it’s microISVs selling desktop software, Web 2.0 sites, or even the big enterprise kind of outfits.

• Brazen Careerist: How to be a star performer: 4 things to get good at (yes, this one’s a year old, but it’s still a good read):
  

  To become your best self – a star, a great leader, a fulfilled worker – you need to know yourself and your goals very well. Start now. It’s a lifelong process, and done honestly, it’s the process that makes almost any job intrinsically challenging and interesting.

Nice reflection on Skrentablog on reducing clutter in your codebase. Code is our enemy:

Code is produced by engineers. To make more code requires more engineers. Engineers have n^2 communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.

You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

This doesn’t apply just to code. It applies to almost everything: less clutter leads to less overhead (of various kinds) leads to improved results. See, for example, Merlin Mann’s recent post on his personal war on clutter.

I read in Ars Technica that Most IT projects in Europe are late. According to the article,

The main reasons for delays, according to the survey, were outsourcing, changed project goals, and poor managerial coordination

The numbers listed in the original BBC article, suggest that the European country more likely to deliver on time is Sweden, where 44% percent of IT projects make or time. Spain and Russia are at the bottom of the list, with only 4% (!!) of IT projects delivered on time.

This is June 2007, more than 6 years after the Agile Manifesto was published. And we still can’t manage the volatile nature of IT requirements. Apparently we can’t really manage much in IT, anyway.

I wonder why is that? Is it really all that difficult to manage customer expectations and work in nearly-continuous-re-planning mode, adapting to changing priorities and requirements?

There are successful IT companies that hardly ever need to push a deadline, so it is definitely possible to do a good job of an IT project and to do it on time, too. So is really the majority of the IT industry so incompetent?

The call for papers for the upcoming Conference on Automated Testing that Google is organizing for September 7th and 8th has been issued! Deadline is June 1st.

More details in this Official Google Blog entry and in this Google Research Blog entry.

I am looking forward to this conference. Test automation for the people!

(link)