Never Clever

When I started at my previous job, we were small-time. Sites were ASP or (horrors) ColdFusion talking to an Access database, and even that was only for fancy clients who wanted a record of the Contact Us form submissions from their site. We got a little bigger and a little better and we started rolling out small tools to manage pieces of sites (typically press releases or job postings). Again, ASP talking to Access. Like Mike Mulligan and his steam shovel, the more we worked, the better we got and then, like Mike, we dug ourselves into trouble. We built a site for a client with enough web traffic that Access couldn’t keep up (hard to imagine, I know).

Enter SQL Server. We tried to keep up the pretense this expensive piece of software was a one-time thing, but success here bred more work and attracted more clients who could justify the expense of a machine and a SQL Server web connector license or whatever the hell it’s called. This left reusable bits of code all over, but we didn’t have that many clients who needed their own server. We sucked it up and added a shared SQL Server for mid-sized clients so we could keep using the same code. At this point, some of the most inventive work being done in development was justifying why a new site wouldn’t work with Access. It wasn’t long before that second shared SQL Server came on line. Our codebase was driving our hardware and platform decisions.

This ossifies a company: if you can’t take on jobs smaller than six figures because you can’t hide the software licensing costs, you lose out on smaller jobs. That doesn’t look like a problem to a company in this state because they’ve developed a mindset that says, “We only work on projects that are worthy of our time and platform” (at The Daily WTF, this would be called “enterprise-y”). There was no reason we couldn’t have put MySQL or Postgres on Windows and gotten 90-100% of the same performance for free.  Small projects don’t add a lot to cash flow, but they can be portfolio pieces, they can turn into bigger jobs, they can create connections that lead to bigger jobs. If they do none of those things, they do wonders for development teams. They’re calisthenics. Clients with small budgets don’t have small plans; they want everything the guy at the next table is having, they just don’t want to pay his tab. “Do more with less” was the derisive slogan of the final season of The Wire; when it comes down from management, it is worthless. But when it’s baked into a (well-managed) project, it can force developers to step back and figure out how they can recreate the code they’ve been cutting and pasting in a smaller space. That’s the kind of challenge that not only keeps developers learning, but keeps them interested and in fighting trim.

Dearest Self,

When designing and building a system, don’t just treat the base-level objects as black boxes (”as dumb as they can be, but no dumber”), but the modules they roll up into should be black boxes as well. That way, when you get pulled off progress on one of the modules, you can just tie things off and leave them. If they don’t support the few places they interact with others, they’re not done yet. Also, documentation never hurts.

I’m coming to (near?) the end of what can only charitably be called a “difficult” project. Unfortunately, I don’t think I will be working with any of the parties involved in the future. For future readers and my present sanity, this feels like a good time to define what I don’t do for a living; sometimes that negative space tells more about a thing than the thing itself.

I don’t work without specifications (requirements). Real specs, not three pages of bullet points in Microsoft Word. You don’t have to know it all when we start and it’s part of my job to get those requirements right, but it is a bad idea to put hands to keyboard before I know exactly what I’m doing. Every development project changes in definition from when it starts. That’s the beauty and pain of requirements. You sit down thinking it’s stupid to have to tell me what to do and then we start talking about what to do and the conversation chases dozens of tangents. Ratholes appear. Better to find them up front and deal with them (or pour concrete down them) than find out “Later”.

I don’t put together the requirements without talking to you. I don’t know your business, you do. Even if you just got hired last week and this is your first assignment, you still know better. You know who to ask (and who the office gossip says to avoid), you know where to go for answers outside your company and you know how to ask relevant questions that get helpful answers (compare and contrast with my: “So how do you guys ship stuff to people?”).

I don’t build the system for you. I build it for your customers, your users. It’s rare that you’re going to be a perfect example of your customer and even then, no. You can’t serve two masters (the application vs. career success). This doesn’t mean every project has to involve one-way glass, video cameras, white lab coats and a testing facility, but it does mean putting together some kind of test, even if it’s just simple hand drawings of screens to show to random folks in the hallway to make sure we haven’t missed something glaringly obvious. Oh, and about those paper protoypes: I don’t work without some kind of screen mockup. It doesn’t need to be the Sistine Chapel. It doesn’t even need to look like the final screen. We just need some kind of reference so when I hand in my work, there’s an agreed-upon set of things that should be there. This also saves me bugging you in the middle of the night, so invest in your sleep up front.

I don’t know anyone that handles scope creep well, but let me define that in my terms: changes or additions to the requirements after they’ve been fully thrashed out and after work has begun. Even as an hourly contractor, I get skittish. “Hey, it’s just more work for you.” Sure. But if it affects things that have been finished and vetted, it’s A Bad Idea. However, things come up and needs change. My rule of thumb is that if the change would alter how data is stored, then let’s suck it up and do it now. Otherwise that means the work has to get done later and data migration will have to be done. Better to do one difficult thing now than one difficult thing and one risky thing later. If it doesn’t change the data, we should talk about creating a “Things for the next version” list.

I don’t work without a QA person or team. This doesn’t have to be anyone with a degree and 100 years of experience in Quality Assurance. It just needs to be someone other than me who can run through the system as a user, spot things that don’t match the requirements and tell me about them in a meaningful way, e.g., “Here’s what I did, here’s what should have happened, here’s the big explosion I got instead” as opposed to “COMPUTER BAD!” I’ve never met a developer who could qa their own work, myself included. After spending weeks or months or years designing the flow of things, we have a bad habit of “testing” the system by using it in the exact fashion it was designed (”Click on this button, then give it a value between 1 and 10 but never a decimal and then wait five minutes”) instead of beating on the thing until it can withstand all challenges.

After all that, surprisingly, there are some things I do do*. Email me at tclancy@gmail.com if you want me to do them for you.

I know it comes out like “doo-doo” and I know that was a poor way to phrase the fact I know it, which was even more fun.

This post exists as a note to myself so I can remember the pain. So far:

7:30am - My old copy of Agile Web Development with Rails may be more of a hindrance than a help. It’s from the days of yore (Rails 1.2 or so) and I’d like to work with the current 2.0 version of Rails, but this means some of the book’s command-line instructions have to be ignored and the “modern” equivalent found online. Turns out database tables get created in a “user-friendly” migration instead of the older convention of raw sql files. I’ll need to find the way to add indicies and other db tuning info to the migrations. It’s all irrelevant if I can’t figure out why my model doesn’t show any fields when I try to create it in the admin. I either fouled something up using the old conventions or there’s some miscommunication between Rails and MySQL (it groused about not having the mysql gem installed a while back, but I installed it– of course, that barfed when trying to install its documentation, but it said it installed correctly and I don’t see the log warnings anymore). I feel like Aptana is more of a hindrance than a help right now as I’m drowning in options and ways to investigate what’s going on.

7:45am - Going back and reading the link above in a more linear fashion, it does clearly say “no dynamic scaffolding”, which may be my problem, that I’m trying to rebuild the scaffolding over what I initially generated. All I see when I go to the scaffold page is a create button with no fields. Pressing the create button adds a record to the database, so it’s not a db communication problem (whatever it is, it’s the same problem described by James here with no solution provided). I just went back, deleted all my databases and all the files/folders I could find related to the one model I’ve been trying to create (User). And that . . . did not work. Awesome. I can see why people love this so. It really is like magic.

7:50am - Ok, so I’m a little dim. Apparently “no dynamic scaffolding” doesn’t mean “There’s a new way to do this”. It means “Gone”. Either I’m really stupid or the tutorial linked above dances over some bits that need doing. Moving on to this tutorial since it seems to address this problem. If nothing else, I learned that I could do the Model & Controller destruction via script instead of deleting the relevant files by hand. Really helpful when starting on a framework or language, which is usually a set of fits and starts. That worked, but it took two tries. The first time I did it without specifying the fields at the command line, e.g., “ruby script/generate scaffold User”, then added my fields to the migration and ran the db:migrate task. Nothing doing. So I destroyed the model & controller, re-ran the generate with all my fields listed in the line and then restarted the server without bothering to run db:migrate (the new 001_create_users.rb matched the older one exactly). It would appear the key difference is that the second run offered to overwrite the user views. Not sure if they weren’t there the first time around or if I did something different. Either way, it works. And I got about 3% of where I wanted to get in the first 2 hours.

8:10am - A discussion that explains things a little more clearly. It makes sense that the scaffolds are just a starting point, but the one thing that puts me off Rails every time I start up again is the attitude of the community. It’s endemic. I tried to get help in IRC once and anyone with a question is treated like an ass for not being part of the club. I do this for a living, I just don’t do it in your language and framework of choice. The community feels so closed-minded, but closed in a really interesting way, because I’m either getting too old or there’s a stink to the Rails Borg that makes it an Insiders Club no one but misanthropes would actually want to be accepted into. I have a Powerbook and a copy of Textmate. Neither of them changed my life. If they were gone tomorrow, I could cope. My simplistic observation of how to “belong”:

1. Mac laptop
2. Textmate
3. Glasses
4. Short haircut

Actually, I have all of that. Still not interested. I should point out your development machine needs to be a laptop so you can develop on the road at all the places no one is ever going to ask you to go. From that discussion: “dynamic scaffolding was a crutch that kept people from really getting Rails from the start”. See? It’s not about being able to get whatever you want done. It’s about learning Ruby and Rails and falling deeply in love with them. Bad enough when developers lose sight of what an application is supposed to do for people and start gold-plating features because the app becomes an end goal in itself. This guy wants you to move another step of abstraction past that: you need to spend some time learning the framework upfront. He’s not so much turning the value proposition of Rails upside-down as he’s throwing it out. I’m guessing he has full-time employment with no real deadlines.

Starting a project is one of those moments of sheer pleasure for developers, the clean sheet. While you’re laying foundations on web apps, you often need some way of interacting with the plumbing. Old friends may remember “Peterson Style”, named for an ex-coworker who would roll 16 pixel Times New Roman black on white up ’til the last second he could get away with it. After a few years of working with world-class visual designers and usability folks, it pained me to do that. The first thing I usually do is create a tiny stylesheet that adds some padding to the page and changes the font to something less grating. Along the way I’ll play with potential interactive bits for the interface, which is one of the ways I got involved in the usability and interactivity discussions at work in the first place. Now that I’m off on my own, this gets a little more challenging. When I’d spent years with a team, people had no problem telling me to remove some overly rococo bit of JavaScript widgetry, but when you don’t each other, it’s a trickier conversation. Plus people assume you have some emotional investment in what you put on the page; only the most autistic are going to roll right over something someone spent time on (and the most autistic are all other developers, not ui people). But if the choices are fait accompli or accept the average, my inner Catholic schoolboy will go with the fancy Latin everytime.

Using jQuery to coax .NET into cloning table rows with properly numbered id/ name attributes:


var MyNamespace = {
init: function()
{
// attach row clone to passenger table
$("table#tblPassengers tr:last :input").change(function() {MyNamespace.cloneRow("tblPassengers")});

// attach row clone to contacts table
$(”table#tblContacts tr:last :input”).change(function() {MyNamespace.cloneRow(”tblContacts”)});
},

cloneRow: function(sTableId)
{
var oRow = $(”table#{0} tr:last :input”.format(sTableId));
oRow.unbind(”change”);

var oNewRow = $(”table#{0} tr:last”.format(sTableId)).clone();

$(”:input”, oNewRow).each(
function ()
{
MyNamespace.cloneInput($(this));
}
);

$(”table#{0}”.format(sTableId)).append(oNewRow);
$(”table#{0} tr:last :input”.format(sTableId)).change(function() {Flights.cloneRow(sTableId)});
},

cloneInput: function(oInput)
{
oInput.val(”");
var oRegex = new RegExp(/[^”]ctl(\d+)/g);

var sId = oInput.attr(”id”);
oRegex.exec(sId);
var iIdCount = parseInt(RegExp.$1[1]);
var sFind = “ctl” + MyNamespace.padIntegerString(iIdCount, 2);
var sReplace = “ctl” + MyNamespace.padIntegerString(++iIdCount, 2);
oInput.attr(”id”, sId.replace(sFind, sReplace));
oInput.attr(”name”, oInput.attr(”name”).replace(sFind, sReplace));
},

padIntegerString: function(iInt, iNumberOfCharacters)
{
var sTest = iInt + “”;
if (sTest.length >= iNumberOfCharacters)
{
return sTest;
}
var sPad = “”;
for (var i = 0; i < iNumberOfCharacters - 1; i++)
{
sPad += “0″;
}
return sPad + iInt;
},
};

2.0.1, actually. Now I just need an excuse to use it somewhere.

We get along so well: