The desire for perfection can paralyze software developers. Sometimes we know the gist of what we want to write but not which names to use or the constructs to define. So we stare at our blank screen and cogitate. We ponder, pondering our pondering, and ponder our pondering of our pondering.
To overcome paralysis, for small chunks of code, it is often better to just write whatever comes to mind – no matter how awful it may seem at the time. Give yourself permission to let the first version suck. You may even *gasp* not TDD (“Test Driven Development”) it. Just make it work. Just do it. You’re only pushing bits around on a screen. You can change it later! For those of you who always alwaysalways test first, this may even feel a little liberating (while feeling a tad naughty in a good way).
This is not software development technique. This is a productivity technique, pure and simple, straight from the writing of David Allen of Getting Things Done.
Also this is not justspiking. Spiking is, essentially, prototyping a small problem area for learning purposes. We’re not going in planning to throw code away – only our standards but only for a few minutes.
At the very least, this approach will serve the same purpose as a spike. You’ll better bound the problem, you may have a partial or working solution, but you have concretely captured the problem at hand. It sure beats the alternative of having an amorphous concept bouncing around your noggin.
How often do I do this? All of the time. For every piece of code, blog post, or email that I write, I blurt out whatever comes to mind first then I refactor (although, yes, I often, but not always TDD it when writing code). And when I refactor, yes, my standards come back into play. It works. Try it.
If you’re reading this, you’re probably looking for a few hands to work on your startup. You’re probably also tight on funds. And, so, you’re considering giving away a stake in your possibly yet-to-be-realized vision.
Since I’ve begun offering freelance services about a year ago, I’ve had several customers offer to compensate me with equity. I have yet to meet a single freelancer who took an engagement with a customer offering equity. Most of us won’t. I never have.
Once I hear “equity”, I’m typically turned off like a switch.
Freelancers, in particular, are in business for themselves. Most of us don’t want to be tied down to a single startup unless its ours. We may even be looking to develop our own products.
Instead of payment, you’re offering equity as compensation; effectively, you’re asking us to invest in your startup. Most startups don’t have successful exits. The common perspective, then, is that your equity offer is worth only the paper or electrons it’s printed on.
You may be able to retain neophyte developers who are looking to build up their portfolio but you probably shouldn’t. Some of them will work, effectively, for free. However, typically, you get what you pay for. A novice developer is just as likely to give you negative productivity than a usable product.
Before spending an hour telling us all about your glorious idea, first determine if you can possibly close us. Pitch us as you would a real investor. But you ought to be sure that we’re at least open to the idea. You’re almost certainly wasting yours and your prospective developer’s time if you don’t first. Again, most of us aren’t interested. You’ll save yourself a lot of time by asking the simple question of “will you work for equity?” first. Feel free to ignore this if you enjoy spending a lot of time pitching people and having nothing to show for it.
Remember, you are asking us to become an investor. Sell us on you. Sell us on your idea. Coffee is for closers!
Maybe, just maybe, you’ll get a quality developer out of the process. But you have to remember that you’re asking that developer to be an investor.
Over the past several months, while attempting to develop my previous business and now a new one, I’ve immersed myself in books about entrepreneurship and marketing. Most of them promote ideals that I already adhere to: authenticity, honesty, building trust, and the value of relationships. I don’t adhere to these principles out of a desire for fiscal success. I adhere to them because it is who I am, win or lose.
If you are the least immersed in popular culture then you have undoubtedly heard the phrase “Business is business.” During my career, I’ve encountered this phrase more often than I would like.
I am frustrated to occasionally see seemingly otherwise decent people descend to morally questionable depths when money becomes the issue at hand. It is as though business is this separate world where Machiavelli is welcome even though in this other world that we call “life” he is not.
If you’ve seen the HBO series “The Wire”, “Business is business” is the sort of utterance that one of the corner drug dealers may say after ratting out a pal to save his own skin or gunning down a comrade who earned the ire of the kingpin. It is an excuse for breaking social contracts in favor of financial gain. It is a rationalization for what, in otherwise friendly company, is selfish and often unkind behavior. It is a dirty excuse for blithe indifference.
Instead, I prefer to say “Business is personal” – because it is.
If it’s truly not about whether you win or lose but how you play the game then how we do business may provide the ultimate example of ourselves. At stake is no less than the welfare of ourselves and our loved ones but also who we are: our moral character.
What says more about who you are than how you treat other people when the stakes are high?
How do you want to be seen by the world? How do you want to be remembered?
I always give a straight answer. Sometimes that answer isn’t the one that you want to hear. However, I believe that hiding the bad news from you only weakens our relationship and your project.
I want to see you succeed.
To that extent, I will help guide you through the process, providing my insight to add value to your business. At any given time, if you’d rather that I do it your way, I’m open to it, because….
I want my customers to be happy.
Few software developers and consultant realize it, but the software development consulting business is, first and foremost, a customer service business. If you’re not happy then our relationship will not be mutually beneficial. And I always seek the WIN-WIN.
I ship.
At the outset, we will agree on a release date/window for your product. We will together prioritize the features that you need for your Minimum Viable Product. This is part of the agile development methodology that I loosely follow. This will also likely define your first release. And it will ship on schedule.
I believe in forging meaningful long term relationships.
Engaging me alone, or with several of my peers, is not engaging a business but forging a relationship. Good business is built upon the understanding and trust in that relationship. The better that we understand one another, the better we will work together. From day one, I am trying to understand you and your needs to better add value to your business. Trust comes with everything else that I’ve already cited above (e.g., candor, shipping).
Please do feel free to contact me with opportunities at sleight42 AT gmail DOT com. Subsitute the “AT” and “DOT with “@” and “.” for the actual email address.
One of our clients sells customizable products. He contracted us to write a webapp to facilitate the process for his customers. We decided to go with Spree for the integrated eCommerce and order fulfillment capabilities. Having written eCommerceimplementations before…
The trick then became how we would represent these user customized products. As it turns out, Spree supports this in the model out of the box. In Spree, products are represented by instances of the Product class. However, they can also be represented by Variants of a Product. That is, a Product has many Variants. Variants can vary by price but they also can vary by OptionValues.
I know: OptionValues is quite a mouthful of generic stuff.
But they’re useful! Let me explain.
In Spree, a Product can have multiple OptionTypes. Each OptionType describes what amounts to a container for an enumeration. The OptionType then has OptionValues. These OptionValues are the values in that enumeration. And Variants have many OptionValues.
When you put it all together, it looks something like this:
Now that is one tasty burger!
The only downside that I see is that, for one-off/user-customized products, at a minimum, you will be creating a Variant with permutations of OptionValues for each line item in a user’s order containing a customized product resulting in a cluttered products table. If you’re willing to do a little extra work, you could probably elaborate upon the Spree model to determine if a Variant already exists with your desired permutation of OptionValues before going off and creating one.
My name is Evan Light and, yes, I am a nerd. I’m also a professional software developer who, after spending one too many years contracting to the federal government, escaped into the far more enjoyable commercial world. Having spent several years using C and even more using Java (the latter very nearly caused me to give up programming entirely), I consider myself fortunate to have discovered Ruby and to use it as part of my daily work.
