Thursday, July 16, 2009

Legacy Doesn't Always Mean "Old"

I've decided the EOL website development project is a "Legacy Code" project.

That may seem a bit naive, since it's really a start-up project that's two years old, give or take.  However, there are three reasons for my decision.
  1. Because it was a rapid start-up project that was done without "real" Agile development.  It accrued a surprising amount of code debt in its early days.
  2. Because the database is non-Rails in some serious ways. Particularly in its use of compound keys and the fact that it's spread over three databases instead of one.  There are good business reasons for these decisions, but they affect our use of Rails.
  3. Because of the lack of robust testing.
It's the latter case that I am most interested in addressing first and with highest priority.  Our team agrees, but also points out that there is a lot of work needed in the area.  We have lots of tests!  But they are difficult to use, fragile in some cases, slow, and so on.  Given these problems, we had a 90 minute meeting today, where we asked four questions:
  • What are our overall testing goals, really?
  • How well are we achieving them, currently?
  • What are the most pressing needs?
  • How can we best apply our time to improve tests?
I found these to be very effective!  To answer the first one, we developed the following three answers:

  1. Facilitate careful development (TDD).
  2. Prevent regressions from being deployed.
  3. Create enough trust to allow refactoring.
To the next three questions, we had a lively and effective discussion, with lots of excellent ideas and approaches discussed.  The end result was a list of concerns, another list of "action items" to address the most important among them, and, interestingly, a list of "philosophies" about how to approach tests.  They are somewhat specific to EOL, but they were cool enough that I feel compelled to share them:

  • View and controller tests are really much like "unit" tests, since they are testing a method on a class... it's just a different "kind" of class.
  • It's okay to throw away unit tests (including controller/view), as long as the features they are supporting are all tested with higher-level tests, and those tests are passing.  Implementation methods change, some of the requirements of the past are likely to change, too.
  • Try to write tests that are not fragile (meaning: refactoring doesn't fail tests).  The underlying idea is that when a feature is complete, all tests should pass and when the feature is incomplete, some tests should fail.  Period.  The interals are less important, though someone may have a need to test them (at the Unit level) to help with developement.
  • The blackbox, factory approach is more appropriate than mocks and specs in EOL's environment. But we need to make the domain logic approachable to developers (new ones in particular).  Copy/pasting solutions from other tests /works/, but is not ideal.  We need to make this easier to use, more convenient.  Developers should /want/ to write tests, becaise it's easy to do.  Newcomers have varying levels of domain knowledge.

Friday, July 10, 2009

On Creating Effective Web Interfaces

At EOL, we've been asked to implement some new features that we (the developers) didn't like. They didn't seem to adhere to web-standards, didn't look particularly good, and didn't really seem to capture the problem (caveat: as we see it) elegantly.

This sparked a discussion (healthy, not heated) about how we could best approach design and web usability as we add features. Another developer wrote a blog-post about it.  (...internal-only; sorry, no link for you!)  I felt compelled to talk about the same subject myself and field some ideas.  His post was all well-formatted, edited, and technical.  Mine is casual and sloppy.  So it goes.  ; )

So what's the problem?

We're using Agile methods, so the proximal problem--which we are already trying to address--is that the temptation is strong to just "get something out there".  Users can respond to it, and we can quickly adjust our approach to build something they will like better.

This has a few negative consequences:
  1. The code gets ugly and risks leaving remnants of old styles when it changes.  Have a look at our CSS, for example.  :(
  2. I think users can get scared away.  At least for me, I know I've tried to use some feature of, say, Yahoo! Mail, hated it, and never looked at it again.  ...They may very well have cleaned things up later, but I don't care to look.
  3. User feedback tends to... well... suck.  In my experience, they'll ask for things that actually result in clutter.  Also, it's only the squeaky wheels that get heard, and their needs may be vastly different from the majority.
  4. There is a big but poorly-understood difference between a feature that's easy to use and one that is "intuitive".  The latter implies that a newcomer can step in and use the tool... well... intuitively.  This is great!  But it often creates an interface that wears on your quickly, or ends up something you hate over time.  Photoshop's clone tool is a good example of a tool that's easy to use, but not at all intuitive.  It's important to know which is better for your problem. I think that user-generated feedback generally comes from users who have tinkered with an interface for something on the order of minutes.  They're talking about intuitive use, not easy use.
...There are probably others, but I'm getting bored.  ; )

The core problem, I think, is that we really need someone skilled at web interfaces.  But we don't have the money to add someone to the team to do this, and everyone currently on the team is too busy to pick up the skill and/or apply it at the expense of their current duties.

In short, we are left with only one option: establish some guidelines by which we can do the best we can, on our own.

To that end, I like the idea that my associate mentioned (interestingly enough, by quoting yet another associate of mine): a list of usability questions that can be asked to gauge whether an interface works or not.

...I think this is a reasonable start.  That said:
  • I don't know who we should ask these questions.
  • I worry that we'll end up with design-by-committee interfaces, which usually suck.  Ideally, I hope that design can be limited to two people on any given feature.  ...Ideally-ideally, the same two people on every feature, to maintain consistency.
  • Nothing in the questions mentions web standards/best-practices.
  • I worry that this is going to take up more time than we have, and breed frustration at the slow implementation of new features.
  • I think the questions are good for measuring usability, but there are other concerns, such as intuitive-vs-easy, elegance, and the "message" conveyed by each feature.  I hope we can add questions into the mix so that these things are considered.
  • I think it's worth investing two or three people's time over a day or two (each) to research usability, and contribute to the "checklist" that we're building.  This could include best-practices, design methodology, questions to ask, and the like.
I could go on.  This is a fascinating subject with many different possible solutions.  ...Sadly, I don't think any of them are even remotely as good as "hire an expert".  : (