This is a test of Flock

Hmm. Why would I want a different browser. Doesn't Firefox just do what I want? And if it doesn't do it, can't I just get a plug-in to do it?

Yes, yes yes.

But this is a browser that is more tuned to what I do day-to-day: Flock. It's pitched as a social network browser, but it's more like a web2.0 browser. Right now I'm writing this blog post from within a separate window... I chose "New Blog Post..." from the file menu, and I was off. It knows about my account, and takes care of the details. Not that blogger has such a bad interface (it doesn't), but it always feels better in a real window.

Working with Agile Developers

I recently joined Carbon Five, a small agile consulting company specializing in boot-strapping start-ups. I got a chance to work with C5 over the last year (as a client), and I learned that the expectations of working with us are very different than working with other consulting companies.

What is agile

Agile is a software development process emphasizing:

• close collaboration between the programmer team and business experts, or in our case, between the client and developers
  


• face-to-face communication (as more efficient than written documentation)
  


• frequent delivery of new deployable business value
  


• ways to craft the code and the team such that changing requirements is not a crisis.
  

Agile teams strive to collaborate in-person as much as possible. And we deliver software not in just a few key milestones, but continuously: weekly, daily or hourly.

What to expect from us

Working with us is collaborative and iterative. You tell us what you want, we listen, and together we identify the most important features. The goal is to identify the features (or "stories") that provide the most value to you and your customers. Once we agree, we will build it quickly-- not in months or years, but weeks.

We will deliver this early version so you can try it out. Once you experience it, you will likely have a reaction-- a good one, we hope. But if you don't like what you see, that's fine. We haven't invested much, and we are early in the process. We can easily adjust what we're building. It may inspire new ideas or a change in direction. Whatever the reaction, we're not locked in. Hence the term "agile".

We meet again, and prepare to repeat the cycle. Again, we'll address the highest-value aspects of the project, deliver them, and we get feedback for the next iteration.

What not to expect: we are different than an "outsourcing" experience. In that engagement, you expect to tell the agency what you want, and they deliver it to you in three or six or 12 months. (Easy? Yes. But it seldom works easily.) We expect you to be engaged in the development process, defining requirements, setting priorities, and providing feedback.

Why agile

Agile, and the related methodologies like scrum, extreme programming, lean/agile, is a response to the failures of "traditional" software development. Even though the "traditional" process has been around for nearly 40 years, it has never worked particularly well.

• 64% of features included in projects are rarely or never used
  


• The average project exceeds its schedule by 100% and nearly two-thirds of projects significantly overrun their cost estimates
  

Agile, with its different emphasis, addresses these:

The most common reasons for software failure are unrealistic or unarticulated project goals and badly defined requirements. We build working software in collaboration with our customers. By collaborating, we identify missing requirements right away (and resolve them with you.) And our customers see problems right away, and get a chance to respond to them. This tends to reveal right away when our goals aren't aligned.

The other common problem is communication among customers, developers and users, and poor reporting of the project status. Agile addresses these head-on. At it's core, it's about communication. The team meets daily to identify problems, programmers work together ("pair"), and the customers are involved frequently during the development of features. In addition, software is delivered and reviewed frequently (usually every two weeks), so the team-- even if there is some huge misunderstanding-- rights the ship before it can get too far off course.

What we expect from you

Collaborate with us. We expect to be collectively figuring out, and then building, what you want.

Here's a typical cycle: We will periodically (every couple weeks), have a planning meeting. Here, we talk about what you want: this will be business goals, product features, and perhaps "the color of that button over there." Once all the ideas are on the table, we will estimate the amount of effort they will take to get done. These are estimates, but help you prioritize the work: a medium priority feature may be worth doing if it's really easy, but should be shelfed if it is a huge undertaking. We keep the developers involved so you can make informed decisions. We need to you to be actively engaged in these meetings and strongly representing your needs. The outcome of these meetings largely shapes what we will do over the next iteration.

We will expect a daily engagement. We will need you, or your delegate, to answer product questions throughout the business cycle. By foregoing huge, unmanageable requirements documents and product specifications, we have saved weeks or months of time. But when we do run into a question, like (insert example here), we need the ability to get an answer fairly quickly so that we can move forward.

Finally, we expect you to make time to look at the working software we deliver and respond to it-- not wait three months until the project is done. Expect from us working software.

Notes:

http://www.agilemanifesto.org/

http://www.agilealliance.org/show/2

http://www.it-cortex.com/Stat_Failure_Rate.htm This article aggregates several studies on software failure rates.

http://spectrum.ieee.org/sep05/1685 Why Software Fails, Rober N. Charette, September 2005. Summarizes why projects fail.

Unit testing time

We've all run across the problem of trying to unit test some code that is dependent on the current date. Such as:


public String elapsedTime(Date d) {
final Date now = new Date();
final long ms = now.getTime() - d.getTime();
return "" + ms / 1000 + " seconds ago";
}


How do you test something like this? (or something more sophisticated and useful)

I found the solution in a posting about mock objects. The trouble is that this code is depending on the Date class, and its behavior of getting the current time. Imagine a Clock interface:


interface Clock {
Date getNow();
}


and then a rewritten elapsed time:


public String elapsedTime(Date d, Clock clock) {
final Date now = clock.getNow();
final long ms = now.getTime() - d.getTime();
return "" + ms / 1000 + " seconds ago";
}


Obviously the Clock can be injected in other ways, but now we have a testable and extensible method.

Scriptaculous Effects Demo

I threw together a demo of Scriptaculous effects: http://ndpsoftware.com/ScriptaculousEffectsDemo.php Nothing crazy here, but I'd like a flexible and interactive demo. Send me ideas or suggestions, Andy

Powerbook Battery Rejuve

My aging G4 Powerbook battery slowly died over the last month or so. It just seemed to hold a charge less and less. Last week it wouldn't go on for more than a minute or two. This weekend, unplugging the power cord was equivalent to a shutdown. After that, the battery reported "missing". It seemed like a strange progression-- not as organic, following some sort of decay curve, as I would have expected the material to behave. So I looked on the Internet to see if there were any clues. There were a set of my batteries that were recalled, but (damn), mine didn't qualify. Next, I found a thread about resetting p-ram and other such shenanigans. I was skeptical, but it seemed like there was one trick that worked for people: going into open firmware (Restart with Cmd-option-O-F pressed), and then resetting the chip that manages the battery power (reset-nvram). It was worth a try. So I did this. Wow, what a transformation. Now my battery seems to hold a charge just like it did a month or two ago. I haen't gone through extensive tests, but it's workable again. Perhaps that other dead battery will come to life... -- report from a year later -- Battery life wasn't that great for very long. It decayed to be mostly unworkable after a month or two. After a year it was down to ten minutes or so, but never as bad as before. Yeah, I've bought a new battery.

Page layout options

I put together this little experiment to show the options and technique for doing different page alignment strategies: fixed width, stretch to the browser, or various hybrids you see around the web.

My question was,

can I just wrap a site in a div or two and then decide this later?

YES!

http://ndpsoftware.com/experiment/css/stretch.php

First grade first

Is using temporary variables was messy? I now advocate writing 1st grade code. By that I mean "See Dick run. See Jane smile." etc. Hey, we're all adults here, you say, why can't I write real code.

Well, writing really simple code makes debugging easier. What do I mean? I've had a couple occasions in the last week where debugging would have been easier if I'd writing really simple code. For example, I just got an null pointer exception here:

          _dataSetsNeedingCleanup.add(new DataSetRef(state, dataSet.getId()));

I can't easily tell where the problem is coming from. It could be one or two places: my member variable _dataSetsNeedingCleanup could be null, or dataSet itself code be null. If I had written it like this,

          final DataSetRef dataSetRef = new DataSetRef(state, dataSet.getId());
         _dataSetsNeedingCleanup.add(dataSetRef);

a stack trace provided by the user tells me exactly what's wrong. This saves me a whole step in the debugging cycle!