A couple of things happened when I decided to go public with NValidate. First, I decided to rewrite it from scratch. There were suggestions I'd received from others that I really wanted to incorporate, and I didn't want to do them piecemeal. I also wanted to review the design and architecture, and that gave me the opportunity to decide exactly what it was that I was trying to accomplish, who my users were going to be, and what I wanted them to be able to do with it once I released it.
I also decided to switch languages. I'm in the process of porting NValidate from VB.NET to C#, and I'm enjoying the experience thoroughly. While I'm doing that, I'm fully embracing test-driven development.
All of these things together have combined themselves to force me to slow down in my approach to the development of NValidate. It's startling to reflect back on my professional experience as a software developer and realize just how haphazard much of it has been. Part of that haphazardness has been my own doing, but a very large part of it has been due to the rushed nature of software development in general.
We always seem to be in such a big hurry to get things done that we cut corners in all the wrong places. A vague statement describing a problem somehow becomes the vision statement which in turn becomes the requirements specification. We slap together a prototype, and somehow the prototype becomes the product. We shortchange testing, shortchange defect resolution times, shortchange staffing ratios, and yet still want it out the door on time. We cut features, go cheap on the aesthetics and documentation, and rush a piece of crap out the door just to beat the competitor to the market. All because the first guy to home base usually captures the market share.
God, how I wish that would change.
It's obvious when you're forced to use a product that was rushed out the door or that was cheaply made. And that's any product; it's not just software. Typically, you know within a few moments of having to use it. It either lacks the features you thought it had, it lacks the power to do any real work, or it breaks too frequently to be of any real use. Some of them, while useful, are so gaudy that you would never leave them out where your friends or family could see them. It's embarrassing to have to use them.
It bothers me to think that some of the software that I've had to work on the past, and some of the software that I've designed in the past, is of that caliber: it's only fit to be shoved into a kitchen junk drawer.
That kind of software need not be a mandate. Rather, it can be a thing of the past if I take the time to slow down and make useful, powerful, well-designed software that people are actually excited to use. But that requires slowing down, and thinking my way through the design, the requirements, the architecture, what the consumers actually want and need, and how to give it to them in a way that compels them to use it.
And that's where my experience with NValidate comes in. (You knew I had to be going somewhere, right?) I've had to stop and think my way through the design and architecture all over again. It's not just me that's going to use it. What do other folks likely want from something like this? How will they use it? How should it perform for them? What languages will they use (programming and spoken)? What are the big design goals (performance, memory footprint, extensibility, maintainability, etc.)?
So in the process, I actually get to do it right. And it's refreshing. I have a vision. I have the design priorities. I have the platform selected, and I have the language selected (and a compelling reason for the language: it's an open standard). I have a rough idea of what I think the end users will expect from it. I have the base architecture sketched out and documented. When I code, I write the test cases first, and then code to satisfy the test cases. There's no fluff. It's lean. It's clean.
Slowing down is a joy. There's no panic involved here. I'm enjoying the project, and I'm looking forward to its initial release. I'm not even really worried about whether or not it's widely accepted by the masses. The opportunity to develop a piece of software that's well documented, using a slow, steady approach to its development instead of a rushed, haphazard approach is rewarding and fulfilling in ways that I never imagined.
I've got twenty years and counting under my belt as a software developer. The vast majority of that time has been spent working at companies where "best practices" were either unknown, paid lip service to, or looked upon as something that were typically beyond the fiscal reach of the firm. But my experience with NValidate has taught me something surprising: my confidence in the product is leaps and bounds ahead of anything I've written before. Granted, it's not rocket science, but I am left wondering if that same degree of confidence isn't directly transferable to larger projects were we to adopt the mantra, "Slow and steady wins the race."
Slow and steady, careful and methodical. Take your time, think your way through the product, and stop rushing through everything. Invest the time you need to design, architect, plan, code, and test. Don't shortchange yourself or your customers in the name of "time to market." While there's always something to be said for getting something out the door, I'd like to think that most customers would rather have something that works and works well, rather than something that looks pretty and blows their foot off.
No comments:
Post a Comment