The software industry is plagued with vaporware and missed deadlines. It's tormented with just as many excuses. Take a look through the annals of software engineering history and you'll see that the craft is anything but a science. Every single software methodology has failed to deliver decade after decade. Instead what you see more often than not is a religious-like following of techniques that worked for someone else, without a real understanding of why.
And yet most software shops cling to them like a life preserver, attempting to force programmers to mind-meld and assimilate with whatever capital-M Methodology the current Project Manager of the year decides upon.
I bring to the table something that every truly talented programmer desires: freedom. I place this freedom right into your lap and let you do whatever you damn well please with it. Because here's the secret to my happiness as a developer:
I create working software to whatever design and specification is in your head right this very hour. You see, the reason every client and developer hates software development is simple.
It's absolutely inevitable and undeniable. The problem with all great ideas is the fact that neither you nor myself have a perfect language defining them. Without getting existential on anyone, your brilliant idea and solution to your needs is only perfect within your mind. Unfortunately, the language of your mind is not Ruby. And so when you describe them to me or to any software developer, they come out only as the woefully inadequate language of English. And because of this, you and I begin to play a learning game.
Most programmers think that they want everything defined and laid out up front, so they can hack away on the product and get it finished and be triumphant. But if a software developer takes a closer look at what makes them happy, they'll realize what they truly desire is making the end user and client happy.
And what makes the client happy?
Next PageWhat exactly is a working product?
And that is precisely what I bring to the table when you come to me as a customer. I give you the freedom to change your mind. I give you the freedom to ask me to rewrite whole sections of your software, every day. In the end, every software project becomes only a fraction of what the original vision was. As the product is built, and you begin to see it take shape and we learn from our growing insight into the product's unique problems, so too does the product change and grow.
This is why I do everything in my power to facilitate the learning process. I leave every Methodology behind. I don't use Scrum. I don't use XP. I dare say that what I do might not even be called Agile. Many programmers would probably say I'm a cowboy-coder, flying along by the seat of my pants. But what I do delivers a working product and a satisfied customer (you!).
So here are the three core tenants of my process:
Previous PageIt's absolutely vital that whatever you are comfortable using, I use that too. It is my passion to take whatever your brilliant idea is and turn it into a tangible product, and forcing you to use my favorite web application or my favorite bug-tracker only hinders that process. If you like Skype, I Skype. If you like e-mail, I e-mail. If you like Basecamp, I use Basecamp. The point is that I handle the feature requests in whatever medium you are comfortable in so you can concentrate on doing what you do best: planning your product.
Another absolutely critical portion of my process is deployments. When I say deployments, I mean getting my work onto a server somewhere so that you, the customer, can see it. This is essential because it keeps you and I in sync. When I learn something, you can be sure you'll learn it too. Gone are the days of waiting weeks to see advancement. I promise you that you'll see them as fast as I code them. This allows you and I to constantly stay on the same page.
Next PageIf the customer doesn't see it, interact with it, or isn't affected by it in real, concrete ways, it's worthless. You will probably never care how many tests are passing at the end of the day, or how many integration specs are green instead of yellow or red. You probably don't care whether my test coverage is nearly one hundred percent or how low my Saikuro complexity numbers are. What you do care about, though, is working software.
I know what you developers are thinking. "Bugs are prevented and covered with testing and good design. Your product won't last if you fail to test/plan/design/insert cargo cult here." If your methodology causes me to take twice as long to deliver a product, though, even an initial prototype, my customers could care less about it. At the core of it all, I am, as Joel Spolsky put it best, a Duct Tape programmer.
Previous PageWhat you customers really want above anything else is to see results that you can guide me on. My customers expect that in a single hour, progress will be made and that bugs will occur and be found as the dust settles. And in so helping guide me in my work, I'm able to see people actually using my software. This leads me to fixing bugs that actually matter, not edge conditions. I will take that sort of testing every single day of the week over whatever process most developers think works.
So what do I have that proves all of the contrarian points I list above?
So what's your idea? Want to see real progress on it in the next hour?