Tag Archives: projects

Getting Better (Or: We Used To Be Worse)

I’m a bit of a pack rat. Somewhere, I have encomia that goes back decades. And in the digital world, this is true as well.

So when I got a new computing device recently and needed to migrate a bunch of data, I had an opportunity to look back at projects we’ve done over the years, and that I had done for at least a decade before. What I found wasn’t all that surprising, but it was instructive.

Starting with my early work, it was, well, fair. I mean, it worked and all (in fact, one web application I wrote a decade ago is still in production use on a public website – think about how much on the web has changed in that time!). But it wasn’t coded all that well, and the emphasis was on getting it done quickly and briefly. (In other words, the code was hard to read and not well documented.)

Then I look at a project from five years later, and it’s all different: sure, sure, it works – that much is the same. But under the hood, the code isn’t just quick, it’s efficient. And there are actual comments throughout. The front-end design and the ‘look’ of the work is leagues better (by that time, I didn’t do it myself, and we had a team with expertise in that area). It’s a professional product.

Then I turn to a project we finished last year, and it’s more advanced yet. The amount of growth isn’t as dramatic, but it’s still there. Development patterns are being used effectively and both programmatic and business logic is easily intuited from the code (and its documentation), and the separation of functions allows for easy manipulation of pieces and parts. It’s a great result.

This progression is hardly unique, I think – every person and every firm, if they’re stretching themselves and striving for self-improvement, has something similar. But we don’t talk about it much, because we worry that clients (or, more specifically, prospective clients) think “we get better all the time” means the same as “we aren’t really ready for prime time yet.”

But that’s pretty shortsighted thinking. Even the best sports pros are always working on their game. We can always improve – after all, that’s the whole point of professional development, right?

It was heartening to see that transformation over the last couple of decades. Who knows what the next project will bring?

When Is It Done?

When you’re working on a development project for a client, it’s often pretty easy to figure out when you’re all done with it.

After all, you did a requirements document before you started, right? So you know you’re done when the requirements are all met, and the client is happy. Easy peasy.

But on a design project, it’s not always so easy. There’s always something more you could tweak. One more adjustment to that logo, one more look at the spacing on that text. Where does it all end?

Well, on projects where we work by the hour, we usually apply what we call the 90-10 rule. If the last 10% of minor fiddling is going to take lots of time and be virtually invisible to the client, we stop at 90%. Then, when we show options to the client for feedback, we review what additional things we could do (and how much time they’d take). That way, the decision is the client’s.

But on projects where we have a flat fee, it’s a little tougher. At some point, there’s a diminishing return, but when you’re immersed in a project, it can be difficult to see it. So as designs are nearing the end stages (before getting final client sign-off), we do an internal review, and have a discussion about what’s where, and what could still be done, and figure out if it makes any sense.

These discussions are often spirited, and also often lead to great design outcomes. We do it on the dev side, too, but usually earlier in the product cycle.

It can be difficult when you’re head is down on a project to see that you’re done. That’s why we rely on others to help.

The Importance of the Side Project

Every job has its ups and downs, not just the job of elevator operator. (Sorry, old and bad joke.) There are parts of the work that are engaging and interesting, finding answers to problems and implementing those solutions. And then there are the other parts — the prerequisites, the occasional begrudging task.

That’s where the side project comes in. Around our offices, we make sure that everyone has a side project to keep them sharp and engaged, even when the primary project might be a little stultifying. This gives our team members a chance to step away, shift gears, and focus on a different matter for a while.

It’s useful not just to provide a palate cleanser for drudgery. Sometimes, we can get so enmeshed in the norms and expectations of a specific project that our vision begins to narrow. Keeping another project on the side enables us to shift that perspective and keep our sights broad.

For some of our team, it’s a passion project — helping reach out to an underserved community through Internet broadcasting, for instance. For others, it’s a project that might end up being commercial one day, like a new and improved nonprofit management system. Still others combine the two, exploring a recreational opportunity app, for instance. (For one of us, it’s writing for this blog!)

Regardless of the specific project, it’s something we prize greatly, and I think it helps us stay sharp and balanced. Because even with the most fun of projects, there’s always a chance to get sucked in a bit too far!