28 February 03 - 21:21Hiring Programmers
How to Interview a Programmer
Dave Thomas: "I think every team of a certain size needs a professional pain in the ass. [...] There are two kinds of pains in the ass: the obnoxious boor—to be avoided on all teams—and the person who never learned that grownups shouldn't ask "Why?" all the time. The latter is a treasure."
I'm sort of wondering what would happen in a team composed entirely of PITAs of the second kind. Just a thought.
- Software Development -
-
§ ¶
28 February 03 - 17:31Speak with intention
The Power of Words
"Talk all you want to, Flores says, but if you want to act powerfully, you need to master "speech acts": language rituals that build trust between colleagues and customers, word practices that open your eyes to new possibilities. Speech acts are powerful because most of the actions that people engage in -- in business, in marriage, in parenting -- are carried out through conversation. But most people speak without intention; they simply say whatever comes to mind. Speak with intention, and your actions take on new purpose. Speak with power, and you act with power."
- Private Life Of The Brain -
-
§ ¶
27 February 03 - 10:46Constructors
Another confused Java learner
I'm finding a lot to think about in the seemingly inept questions that people new to Java ask in the newsgroups.
The person above is puzzled by an error stemming from inappropriate use of constructors. His class extends Applet, a "frameworky" class which only starts "working" properly after it's been put through a few stages by its "container", a Web browser's Java plugin. Thus, obviously, attempts to make calls to methods such as getCodeBase(), which rely on all the setup having been done, will necessarily fail if they are made from the constructor.
The constructor's most important feature is that it gets called only once and necessarily before all other methods on the object.
Why have constructors at all ? That's an interesting question which, if covered by the basic Java texts, would probably avoid such mistakes.
Apart from that, this person's class hierarchy is interesting in several other ways, which all reveal (to me) interesting confusions about OO. I have this idea of an OO course organized exclusively around how people get confused by fundamental OO concepts - constructors, classes, instances, etc.
- Object Lessons -
-
§ ¶
26 February 03 - 20:43It will fluctuate
developerWorks : Demystifying Extreme Programming: Focusing on value
Roy's article seems to be good stuff. But actually, I haven't read it yet - I'm only blogging it for this quote (slightly edited):
When asked which way the stock market would go, J. P. Morgan said, "It will fluctuate."
- default -
-
§ ¶
23 February 03 - 22:23This is highly illogical
To a programmer who finds Vector 'illogical'
This guy has reimplemented Vector, the usual Java class for variable-size lists, because the original implements the workhorse method of the "find" operation (indexOf) in a way he considers "illogical".
What indexOf does is compare the "target" object, passed as a parameter, to each of the elements in the list; checking for equality. This involves method equals(), and can be done in one of two "directions" :
- obj.equals(element(nth));
- element(nth).equals(obj);
This guy's class, call it Foo, has an equals() method. What that equals() methods does is check for equality between an instance variable (let's suppose it is Foo.name of type String), and the string representation of the parameter. It looks like this:
class Foo
public boolean equals(Object other)
return other.toString().equals(name);
Now, what's "illogical" about Vector ? Says this person, this : if you have a Vector containing N elements of class Foo, and given the equals() above, you'd expect the following technique to work when you want to find a particular one:
Vector foos = ...;
int index = foos.indexOf("Name of a foo");
I suppose that the reason our friend would like this to work is that it "saves a lot of typing" if you're calling indexOf a lot. It does look, at first sight, like a convenient notation.
But this, of course, doesn't work, because of the particular "direction" in which Vector implements the equality check. Rather than invoking Foo.equals() with a String parameter, it will invoke String.equals() with a Foo parameter. This will never return a true result, signifying equality between the Foo and the String.
Now, why am I going on about this ? Because I think this is symptomatic of a common programmer's failing.
In our concern with relatively trivial issues (such as how many keystrokes we can save), we often tend to implement nice and clever "solutions" which entirely overlook two very, very important aspects of programming; one concrete and pedestrian, the other more abstract.
The concrete issue is that some unlucky maintenance programmer will most probably inherit our friend's code one day, who will waste hours or days trying to puzzle out why this program needed a homegrown Vector implementation, and probably more hours or days working around some limitations of that implementation, or refactoring the program to use a standard Vector.
The abstract issue, and I don't know which of the two is worse, is that our friend is completely unaware of the
semantics of equals(). As I note in my reply, it is supposed to be a symmetric operation: if and only if x.equals(y) returns true, then y.equals(x) returns true. His implementation violates that.
Programming is like mathematics with respect to abstraction. We are able to deal with complexity better when we define a complex concept in terms of simpler ones. Then we deal with the higher-level concept on its own terms. You don't have to go back to basic number theory every time you want to prove something in calculus, but it's there, at a deeper layer.
When you don't even bother with the semantics of a low-level operation such as equals() - I'm not even talking about making a subtle mistake, but just shrugging off the whole thing because it saves some typing - you are completely losing the benefit of abstraction. You can't think of class Foo in terms of "this class represents that concept", and forget about the low-level details. Rather, you have to think through every bit of your coding at the tiresome level of "it does this, then it does that operation".
I'm not passing judgment. I used to be that kind of programmer. What is sad is how this kind of topic, which is crucial in obtaining programs that work, completely gets lost in the noise of this language versus that, this technology versus that, this methodology versus that. And how much power, how much capability, is lost as a result.
- Object Lessons -
-
§ ¶
19 February 03 - 21:01Long bet on blogs
Blogs to outrank NYTimes.com by 2007 ?
I'd back the 'No' bet. Not because, as the CEO of NYTimes.com suggests, that publication (and other of its ilk) is particularly "unbiased, accurate, and coherent". (No publication backed by big corporate money can afford to be unbiased these days.) Not because, as he also suggests, they have always been a blog anyway. And not because (I'm not making this up) blog writers are journalists.
No, I'd back the 'No' bet because it's likely that in five years, the term "weblog" will have ceased to have any meaning, other perhaps than a quaint reminder of
the Web fad in 2003. It's not a certainty - it's a bet, a hunch. Hmm, I wonder if someone somewhere has bothered to compile a "timeline of Web fads".
- The Universe And Everything -
-
§ ¶
19 February 03 - 14:14Conversations for possibilites
From
A Language/Action Perspective on the Design of Cooperative Work
(Terry Winograd)
"A face-to-face interaction that is identified as playing a particular role in conversations for action (e.g., medication record entry) often has other components (conversations for possibilities) that are lost when it is replaced with computer interactions."
- Private Life Of The Brain -
-
§ ¶
18 February 03 - 16:22Reliable Promises
Reforming Project Management is Hal Macomber's Weblog. It is full of interesting stuff, as well as recent stuff that leaves me somewhat cold - blogs as crucial tools for project management.
Hal's framework of
reliable promises has been rattling around inside my head for months now.
I regularly pick up notions such as Hal's, which present as "tools" for improving behaviour effectiveness. Only rarely do I directly use them as such; rather, they serve as a sort of "lens" to focus my tropisms, to direct my curiosity to this or that category. This often leads to odd coincidences, odd flavors of serendipity, as I discover this or that related idea which suddenly enables me to make more sense of the original one.
In the case of "reliable promises", such related areas have appeared recently, in the guise of John Searle's Theory of
Speech Acts (book added to my wishlist, boy is it expensive), via Fernando Flores' "Language/Action Perspective", which is apparently presented in
this book (another expensive one).
That's the research programme. Meanwhile, I'm still thinking and thinking and thinking about how we use language in our work projects (as well as in other sorts of projects, e.g. in the family). I have some reservations with Hal's framework of reliable promises - in particular with respect to the notion "I know how long it's going to take" - but it seems to me that the interest is spot on.
It's strange how we use language on projects. When I reflect on my experience in software projects, I can think of little examples of using a "language of commitment".
Our language on projects paints the future - we are going to build this and this, which is a cool thing for our software to have. It conveys emotion or judgment - I don't like her work, the stuff he wrote yesterday was brilliant. It exerts authority or power - I want you off this project, it is imperative you complete this by tomorrow. Etc., etc. - but only rarely does it express a pure commitment : "I am going to perform this work tomorrow." (Or, I am going to if this or that condition prevails.)
Many of the "agile" project approaches I'm interested in share a common element - frequent meetings in which participants stand up to declare what work they will commit to.
It's something worth thinking about.
- Private Life Of The Brain -
-
§ ¶
17 February 03 - 22:50Of blog hosts and employers
This reminded me of the old saw, "Nobody goes there anymore; it's too crowded."
"I've been wondering about this blogging thing too... Since I am not doing this anonymously, can I freely talk about what's going on at my work and what I am trying, running into, etc ? Actually, I believe my contract says I can't so perhaps I am stuck with talking about what I do around java outside of work. Anyone solved this dilemna ?"
I've solved Philippe's dilemma by no longer having a job. That works fine, although it has its downsides, such as drastically reduced revenue.
It seems to me more and more assumptions about power and ownership are being built into employment contracts.
The one Philippe refers to is the classic clause "We own what's in your head, however it may have come to be there." This often goes disguised as non-disclosure and non-compete, but don't be fooled.
Another is "It's more important for you to do as we say than to contribute to our bottom line." This is enshrined into French law as the principle that "subordination" is an essential characteristic of salaried employment.
In my work, this has proved to be a serious impediment, because I was as a rule more interested in what I could do to improve the firm's performance (and thus its bottom line) than in doing as the boss was saying.
I thought I could circumvent the problem by going independent. The problem now is that many employers decline to hire me, since, after all, it
is more important to them that people do as they say than to improve their bottom line.
But I don't go there anymore. It's too crowded.
- Blogversations -
-
§ ¶
17 February 03 - 22:09Entomology
AYE Conference
My piece on "Entomology" has hit the AYE conference Web site. Yay !
- Software Development -
-
§ ¶
13 February 03 - 22:38Transposing
Powerful ideas transpose well : you can apply them in domains they were not intended for.
Encouraging signs for
Extreme Programming are
stopdesign - eXtreme Design,
ExtremeGameDev, or
Emmanuel's adaptation to theatrical production.
- Extreme Programming -
-
§ ¶
12 February 03 - 15:45Politics
Seyed Razavi: The end of a craft
(Via
Tesugen.com.)
Seyed is worried about "the industrialisation of our craft". E would rather not have to deal with "large test harnesses", "heavy-weight build processes", "third-party software", "open standards", "a portable runtime environment", or "separation of concerns".
Says Seyed, "These are not technical issues. These are not issues that arise in the process of our craft. They are issues that arise because we work in a political environment." And warns about "our feeling of not being in control, not being craftsmen but being just a cog in a process designed to churn out parts like factory."
In my view, there is no such things as a "technical issue" in isolation, at least not in the field of software. A cog in a factory may be a "technical issue"; find the defective cog and replace it, and you have the measure of the problem.
Software development is a creative human activity; as such it is inherently prone to "political issues". Political issues arise whenever people must cohabit or collaborate for an extended period of time; they are not a problem to avoid, but part and parcel of our nature as social beings.
"Politics", clarifies Seyed, "is my general term for the unspoken requirements that don't stem from either what a functioning system needs nor what users want."
The system doesn't need anything; it is all about what various people want. Among the people who have an interest in what the system does, we certainly find the users. But also the developers, their managers, their families, etc.
Politics is no more and no less than the systems people set up to regulate their conflicting demands upon one another. Technology must necessarily exacerbate politics : it creates
more demands that people can make of other people.
- Blogversations -
-
§ ¶
