Introducing Project Anvil
Hello, and welcome to the "Project Anvil" blog. You are probably wondering what exactly "Project Anvil" is, and why should you care about it? Maybe a bit of back story will help answer that.
In William Blake's famous poem, "The Tiger", there was one stanza that had me asking questions as a child.
What the hammer?
What the chain?
In what furnace was thy brain?
What the anvil?
What dread grasp?
Dare its deadly terrors clasp?
Just what was an anvil? I remember when my teacher said that it was the iron block that blacksmiths use to forge steel weapons and armour. In the poem, it offered imagery of forging the Tiger in one's mind's eye. For some reason, that made a lot of sense to me as a child.
So I find it fitting that when I was looking for a code name for my most recent project that I immediately thought of "Project Anvil". It makes sense to me. I am about to endeavor on the path of "forging" a new product, from vision to reality, in 30 days. One man. One product. Ready for beta in 4 weeks. And the entire process blogged here in both traditional text blogging with screencasts (thanks to Camtasia Studio) peppered in showing some of the interesting things I do during the software development process.
Some of my colleagues think I am nuts. They think its impossible to build something of quality in such a short timeframe. A few people have told me that I am doomed to fail, and that blogging the process is a waste of my time and resources. But I think in the face of such challenges, I can only respond by echoing one of my favorite Don Juan quotes:
The basic difference between an ordinary man and a warrior is that a warrior takes everything as a challenge, while an ordinary man takes everything as a blessing or as a curse.
I plan to pull it off. Maybe I won't. By taking on the challenge though, and letting you see that process, we can all benefit from the experience.
Benefit from it? Well one of the key reasons I am doing this is that I am tired of seeing micro and small ISVs (independent software vendors) complain that they cannot build a business based on quality software because they don't have the same large teams and development resources of companies like Microsoft or IBM. I shake my head when I listen to whining about how they are too small to build secure software and how that in an effort to put food on the table, they can't architect software that runs safely on our platforms of today. And I am tired of watching startups write crappy software because some VC or angel screams "get version 1 out, and worry about making it work later".
Don't feel bad if you are part of that crowd. I mean no offense when I speak of it; I am trying to make it clear just what "Project Anvil" is about, and that you CAN build quality software quickly, cost-effectively and more securely. Some of my colleagues will learn about the processes I use around here and think I am a fool; others who already believe that will re-enforce their thinking and laugh and point. And that's fine. Chances are, they work in a big team and have resources and budgets that we can all be envious of. But from an entrepreneur's point of view all I can do is laugh and point back. And the reason I can do that is that experience has shown me that small teams can build software faster, safer and simpler than you. Oh, and did I mention how inexpensive it is to complete? That through business techniques like building bottom-line pricing grids I can tweak pricing and generate more net profits than you probably do. Sure I'm not making billions of dollars a year in revenue, but that per person in the company, these techniques can help to generate more bottom line profits that you probably do. And as a software company, isn't that a primary goal of our business model... to generate the most bottom line profits that we can? If its not... what are you doing building a software company?
Throughout the month of August I plan to blog the experience of building an entirely new product to solve a pain point some of my clients are currently having. Through it I plan to show you how:
- The use of mindmapping to support agile development can significantly reduce the needs for design specs
- That threat modeling can help empower you to complete effective application risk management during the design phase and expose you to potential design flaws that may make your software less secure than it needs to be
- That you CAN have your development environment firing on all cylinders and pass the Joel Test
- That automated testing can go a long way to validate the form and function of your software and give you better assurance of the quality of your software at any point in time
- That security input validation testing can be more easily integrated into your testing environment than you think
- That the user experience DOES matter and that from installation to usage, just following through with a few critical components can make a big difference
- That you can leverage the APIs of other companies to build solutions for your customer's needs, faster than if you did it yourself
In the end, I hope to show you how I can build a quality product in 30 days, with no real budget and no team. I don't say this to impress you, but to impress upon you that it CAN be done.
And starting tomorrow, I'll show you how.