Interviewing Developers

My preference is to have the candidate bring in their own laptop if they have one, or to use one of ours if they don’t, and not to work on a whiteboard at all, but rather, to work in the development environment the candidate’s used to, with full access to the Internet and all that implies. I believe I’m a rarity in the world, though, as I’ve never been interviewed in this particular way, and I’ve written a lot of software standing at a whiteboard.

Interface or Abstract Class?

I primarily write server code in Java, for context.

I write interfaces in 2 primary situations:

1. Any time I need a contract between major modules, or between my code and code someone else owns. The contract includes the interface definition(s) and all the types that pass through that interface. That’s a package, and is declared as such.
2. Any time I design a general-purpose process which takes different implementations. Right now, for example, I am working on a machine that executes tasks in a sequence depending on the outcome of the previous task. The interface for each task has a single execute method which takes a process status object and returns one of 4 results, all of which are defined in an enumeration.

I seldom write abstract classes—but when I do, they generally implement an interface, and are intended to remove a lot of boilerplate code so implementers don’t have to fully understand the interface behavior to use it effectively. Abstract classes are a lot more common (and have a lot more use cases) in frameworks. Framework developers do this more than server engineers because their software is intended to be extended by others, whereas my software is usually intended as an end in itself.

Sometimes You've Just Gotta Draw a Line

I needed a short line in my HTML UI.  Turns out, you can do it with CSS. Here's the code that draws the specific line I needed:

<div
  style="height: 14px;
  color:white; background:white;
  position:absolute; left:77px; top:8px;
  transform:rotate(27deg);
  -ms-transform:rotate(27deg); /* IE 9 */
  -webkit-transform:rotate(27deg); /* Safari and Chrome */
  width:1px"/>

And here's a general-purpose kit for drawing lines a lot, which provided the clues I needed:

http://monkeyandcrow.com/blog/drawing_lines_with_css3/

So now you know.

An Unreasonable Man

I was having a frank discussion with my boss this evening, trying to work out what's keeping our tiny development team from performing better.  He, nice man that he is, pointed out that "you are a reasonable man, he is a reasonable man, (the third member of the team) is a reasonable man--what is it that keeps you three from being an effective team?"

It wasn't until about 3 hours later that I realized what at least part of the answer is, and it's the root of what's been "wrong" with this team, and indeed, what's "wrong" with many development teams.  I am emphatically not a reasonable man. Where making software is concerned, I'm a distinctly unreasonable man. In fact, I'm pretty sure I'm a complete son-of-a-bitch. And the people I have loved working with the most are, themselves, unreasonable people. As you might imagine, this can cause a lot of friction in a development team, if the rest of the team is full of reasonable people who expect reasonable behavior.

In my defense, I'm pretty sure you can't make adequate software by being reasonable.

A Scout is Trustworthy

I was an Eagle scout.  I also held all the posts a troop of Boy Scouts of America could have, up to and including Scoutmaster. My folks made sure there was a Scout troop I could join wherever we lived; I believe (my memory is fuzzy, and I haven't asked) that they started my cub pack.

They say once and Eagle, always an Eagle.  I always believed that.  The latest overt action by the BSA has caused me to rescind that belief.  I'm sending my badge back, and I'm explaining my reasoning here.

OO, Ward, and Creole

Some interesting reading if you care about code:

Some solid reading on what OO means, and how to test it:
http://www.drdobbs.com/testing/240000411

Ward Cunningham on wiki, languages, and doing the smallest possible thing that works:
http://www.drdobbs.com/jvm/240000393

and finally: how to make your wiki talk to others' wikis:
http://www.wikicreole.org/

Software Fragility

I've been working on the same medium-sized application since March--about 6 months. It's been frustrating. The app is built in JBoss Seam, which I didn't (and mostly don't) know, it has several configuration errors and one serious coding error that has pervasive influence and will be extremely hard to undo, and unbeknownst to me, it has been locking up daily for over a year.

RIP, Steve

Steve. Bill. Larry. If you're about my age, and in the "computer" business, you know who these people are. They're iconic. These three, more than anyone, created the on-line, desktop, hiptop, and palmtop world in which we live. They led the rest of us into a connected world. A world where we're instantly available to our friends and they to us, changing the way we stay in touch. A world where information flows almost effortlessly to wherever we are, changing the nature of discussion and debate, art and science. A world where governments can't hide their oppression, news can't be controlled by those who own the presses,  people can't be told there's no hope for a better life.

Moving away from Google

Recent and not-so-recent posts by a number of bloggers (e.g. 1, 2; just 2 of the 6 or 8 I've read in the past few days) regarding getting locked out of their Google accounts have reminded me why personal computers boomed in the workplace so quickly.

In the early days, PCs (well, except for Macs) were hard to use, had horrible interfaces, minimal software choices (WordStar, VisiCalc, dBase II, and AutoCAD were the exceptions), and were in huge demand everywhere. Why? I think it was largely because they allowed us to control our work. We had word processing, databases, and CAD systems before PCs. They were controlled by others--we could be locked out, inconvenienced, our work confiscated and our access revoked by those in control, without appeal and without warning.

Sound familiar?

Six steps to JBoss (and Tomcat) with IIS 7

I've had a devil of a time getting IIS 7 talking to JBoss. It took 3 different sites and flash of insight to get all the settings working. I'm not a system administrator, and I'm not an IIS expert, so I may have missed a default somewhere or gone further than I needed to. Here's what I did, in hopes it helps you.

Java Components and Package Visibility

I have a recurring problem: I want to build a component within a large application. Here's an example: I want to synchronize QuickBooks Invoices with my application's invoices. The component API produces and consumes application invoices, sales reps, accounts, and customers, but the internals of the sync task are very complicated, involving 3rd-party Invoices, maps to interface invoice-like objects, synchronizers, etc. The main app has no need to know most of this stuff.

Java provides no mechanism to build a subclass structure for my sync component--I must either build the whole thing in a single package containing hundreds of package-scoped objects, or I must build public objects visible to the rest of my app so my component can have an internal package structure which models its behavior.

What I really need is a visibility modifier making classes only visible to their sub-packages.

Creating Healthy Craftsmen

There's been a healthy debate over on the software craftsmanship mailing list about what craftsmanship means in the context of software development. I've been a proponent of, among other things, some set of standards by which a practitioner's capabilities can be measured. That's been unpopular, as you might imagine.

Documentation in the wild

I just started a new project.  I has no documentation except the code.

In this particular project, this is generally a Good Thing--the code in question is clear, well written, and (ahem) completely without comments.  I'm not having a lot of trouble understanding it, overall, because it really is very good code.  But... I've spent 2 days trying to figure out how one important feature works.

http://thedailywtf.com/Articles/Documentation-Done-Right.aspx

'Nuff said.

Kanban in IT

Here's a nice series of articles on using Kanban in an IT setting. I found it interesting because it shows not only what they did, but how their process evolved over time in several settings. http://blogs.lessthandot.com/index.php/ITProfessionals/ITProcesses/applying-kanban-to-it-processes-part-1

Sucking Less: Checking In More Often

I'm fairly fearless when coding, which means that about once a week, I delete a huge chunk of something I should've kept, or change something into something unrecognizable, thereby inadvertently breaking a dozen unit tests. When I discover the problem, usually about 4 hours later, I no longer have any idea what I did that made the bad thing happen. Then I spend another 2 or 3 hours figuring out what I broke and fixing it.  Ugly.

On my personal projects, I check in code every time I get a unit test working. My checkins are something like 15-20 minutes apart.  On projects I get paid for, though, checking in means running the whole unit test suite, and that can take 10 minutes (on a good project) or 2 hours (on a bad one)--so I don't do it very often. That's when I get into trouble.  I've been meaning to solve that problem for some time, and Joel Spolsky's blog topic last Wednesday (Joel on Software) finally kicked me in the pants.  It took 15 minutes to solve the problem; here's how I did it.

Annotating Custom Types in Hibernate

Hibernate has a lot of nice features, and it's pretty well documented, but a recent need to add a simple custom type to an existing mapping left me flailing around for documentation on exactly how to do it. I wanted to do it with annotations, not by updating the Hibernate configuration (that approach is well-documented). Here's how it's done.

java.util.DuctTape

Overview

The proposed class, java.util.DuctTape, is designed as a general purpose fix for a variety of commonly-observed situations in production code. It serves as a temporary patch until a permanent solution is developed and deployed.

Database/Code impedance mismatch

I love natural keys in database design. You have to pay attention, though: the natural impedance mismatch between a programming language representation and the database representation of the key can bite you.

Consider an object whose primary key might contain a date--say, a change log record. Oracle and DB2 both store a DATE as a time containing year, month, day, hours, minutes, and seconds. No timezone. The natural mapping for a Java tool like Hibernate is to map to a java.util.Date, which stores the Date as a time in milliseconds since the epoch GMT, and then maps it to whatever timezone is set on the machine where the code is running for display and conversion.

Now consider what might happen (especially if our change log record is attached to some parent object);

1. We create and save the object; it is persisted. The local cached copy contains a non-zero value for milliseconds, but the database has truncated the milliseconds value and saved it.
2. Later on in the code somewhere, we have reason to save the object again, perhaps as part of some collection operation.
3. Hibernate looks in its cache, compares it with the database, and notes that the values of the Date don't match--so it tries to save the value again.
4. The database dutifully tosses out the spare milliseconds, and bam! we have an attempt to re-insert an existing record, so it throws an exception.

This is all terribly confusing to the programmer, who, inspecting the objects in question, sees no difference between what's in the database and what's in her code, especially since the default display characteristics of her database browser and her debugger don't show the milliseconds.

The easy fix in this case is to declare a class which matches the database representation--in this case, a good choice would be to declare a new class which truncates the milliseconds. A modest example is shown below:

/**
* Public Domain; use or extend at will.
*/
import java.util.Date;

public class DbDate extends Date {
/** increment if you change the state model     */
private static final long serialVersionUID = 1L;

/** @see java.util.Date#Date() */
public DbDate() {
    long t = getTime();
    setTime(t - t%1000);
}

/** @see java.util.Date#Date(long) */
public DbDate(long t) {
    super(t - t%1000);
}

/** @see java.util.Date#setTime(long)     */
@Override
public void setTime(long time) {
    super.setTime(time - time%1000);
}
}

Also note that if you declared the database column as a TIMESTAMP, the Java and database representations more-or-less match--avoiding, in this case, this kind of problem. Note that Oracle doesn't support TIMESTAMP_WITH_TIMEZONE in a primary key, and DB2 doesn't implement TIMESTAMP_WITH_TIMEZONE at all--as of the last time I had access to DB2.

Dealing with timezones is another topic entirely--one which I'll take up in a future post.

Limiting Irreversibility

This afternoon I was reading Martin Fowler's commentary on architecture: http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf, and ran across the following:

At a fascinating talk at the XP 2002 conference (http://martinfowler.com/articles/xp2002.html), Enrico Zaninotto, an economist, analyzed the underlying thinking behind agile ideas in manufacturing and software development. One aspect I found particularly interesting was his comment that irreversibility was one of the prime drivers of complexity. He saw agile methods, in manufacturing and software development, as a shift that seeks to contain complexity by reducing irreversibility—as opposed to tackling other complexitydrivers. I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.

I think he's absolutely on the mark with this--in fact, I think it illuminates one of the two or three key roles of architecture in system implementation. If the architect focuses on helping to define approaches which are hard to change once the system "complexifies", and in helping developers write solid code that can easily be modified when needs change, (s)he goes a long, long way towards making the system flexible and maintainable.

Note that there's two architectural roles there: (1) helping to make key decisions early, and (2) mentoring developers around those decisions.

On most of the dev teams I've worked with, the first set of decisions is made by proposal and refinement--one of us proposes an overall approach, and the rest of us point out tweaks or whole new approaches until the whole thing gels in everyone's mind. It seems to work, if everyone is engaged. Some architects would prefer to "rule by fiat", but I've found that generally results in systems which can't be maintained or in far more work than is needed. It's very hard to get key decisions right by yourself. To illustrate: I once proposed a relatively modest refactoring in a large thorny user interface, to separate business logic from display logic and generally make it easier to maintain. The reigning architect decided we needed a complete rewrite, in direct opposition to the opinion of everyone else on the team. Nobody objected strongly, though everyone quietly agreed that a rewrite probably wasn't needed--it's lot more fun to write new code than to modify old. Nobody asked what the minimum effort needed to meet the requirements was. About two years and a couple million dollars later, the new system is, indeed, quite a bit better-structured than the old one. It's not clear if the new UI will produce allow faster, cleaner updates than the old one--but it sure cost a lot to build: about twice the initial estimate, and about 6 times the original proposal. (By the way: the rewrite is considered a success by all involved. See "What Could Possibly Be Worse Than Failure?" by Alex Papadimoulis.)

A second role implied in minimizing irreversibility is "mentor". Writing good code is hard; writing well-structured code without someone to bounce your design off of is doubly hard. I spend a lot of time talking with the members of my teams, trying to make sure we have a design that's flexible and understandable. A lot of what we think of as "architecture" starts out as a small feature being implemented by a relatively junior developer. I try to make sure (s)he has someone to work with in the early stages of that work, or at least a trial design to start from.

I love Martin Fowler's writing: he always gives me something good to think about.

SEMAT and development principles

My first reaction to SEMAT was--is this practical? But as I've thought about it more, I've decided there are some principles of good software design and implementation they can probably agree upon and illuminate.

For context: I spent 15 years as a practicing nuclear engineer before becoming a practicing software developer.

"Engineering practice", as I found it in the field, is often as arbitrary as "software development practice". What is "good" is measured first by "what works", second by "what's elegant", and finally by "what's inexpensive", and is judged primarily by senior practitioners working against their own experience rather than some set of objective standards (though those exist as well). In hardware engineering, the time lapse between design review and implementation is quite often very long (especially large-scale design, e.g. power plants, where I worked). As a result, feedback loops are even longer and harder to manage. What dominates in the large scale seems to be "what worked"--and just as often, "what failed".

This seems to me to be exactly the type of thing we're developing now as developers--we now have lots of categories of languages for solving different types of problems and we're developing solid tools and techniques for measuring performance, managing projects, and closing the loop between design and implementation. The world for software developers is a FAR less arbitrary place, and has far more development of tools and techniques, than in 1976 when I started coding.

The body of common practice is regularly changing in hardware engineering, as analysis tools get better. When I graduated, one of my first tasks required a stress analysis, which I did with a calculator by hand. These days, an engineer would set that up in a desktop finite-element analysis program with a nice UI, and he'd get a better answer in less time. The principles are the same, though: determine, through an understanding of material behavior and machine design, what a specific application required of the machine and what combination of off-the-shelf components and custom machining could be used to implement that application. It's very much what I do today: I pick off-the-shelf components and custom components to create a design to meet certain requirements.

Can we, as a group, specify some of the principles on which those decisions get made? I suspect we can. While I'm only really fluent in one sub-part of OO design, I know of a few; consider the SOLID principles in OO design, various common design patterns, and the corpus of tools and techniques in Knuth's "The Art of Computer Programming".