I find it quite interesting how many times we hear stories like this about "cowboy" startup engineers. I subscribe to an XP (Extreme Programming) methodology which includes things like TDD, DevOps, and Pairing. I have done this at both existing large companies as well as tiny startups where I was engineer #1 or co-founder (of course, pairing started with engineer #2 ;)).
When people ask me later, how could you do all of that and still run a lean, agile startup environment I always wonder "how could I have been lean and agile without it?!"
Is testing really all that hard? No, I am well versed in testing and pretty good at it. It doesn't get in the way of my process and does help with my design.
Is pairing really restrictive? No, it's liberating! I get to work hand in hand with another engineer to get ideas out quickly, tackle bugs fast, and stay focused.
Is DevOps really a huge problem? It sure is nice to know, early in the development of a new product, that I can deploy RIGHT NOW and continually and have continuous integration and test coverage. There is a lot of value in that.
Do all of these things slow me down? I don't think so, if anything building a new product or company isn't a sprint, it's a marathon.
Now of course the opposite to all of these point are:
Adding tests later is really hard. So is removing technical debt. That hurts, a lot. A newly formed companies can't always cross that chasm.
Multiple engineers all trying to solve big problems without communication can lead to architectural and engineering issues down the road. These are hard to solve. Pairing sure helps with that.
If you can't deploy, redeploy, or move your installation easily, that is a risk to your entire business.
One added benefit of not being a cowboy (outside of your technical debt not biting you later) is in the financing and acquisition discussions become a lot more fun and lucrative. A number of Angel and VC organizations are becoming extremely tech-savy. They want to know if you have test coverage. They want to know that one day your servers won't go down and you won't be spending two weeks trying to remember how to get your entire environment configured. They want to know that their money will be placed in a great investment. These disciplined principles of development go a long way towards showing them that they will meet that goal.
Extreme programming also includes work weeks approaching forty hours...it's about people after all. That sort of approach to work-life balance isn't really to the burn the candle at both ends and the middle rocket fuelled startup aesthetic.
That's not to say that there aren't sound practices there that can be applied to a startup, but XP comes out of the world of consulting where there are clients to prioritize features and decide when enough value has been created to pull the plug on the iterations. So there is a bit of an impedance mismatch between the technique and the brutal reality of going all in for several years.
You are right about the fact that XP pushes for (and should achieve!) a 40 hour week. Again I think it's unfortunate that in the start up world we have thrown out work life balance. As if working 16 hours a day, 7 days a week is a reality that is necessary for a successful start up. I disagree. My two start ups were both quite successful without having to work people more than 40 hours because we had good principles.
We realized very early on that we honestly didn't get a huge amount of value out of the hours after 40. Why do start ups work late into the night? To deploy a feature that is having trouble? Continuous integration and deployment help with that. Adding a new amazing feature that has to be in by morning? When you have a prioritized backlog of features you can tell potential investors or customers when something will be done and they can schedule around that. No need to work until 4am to present at 8am.
I guess I am very against reactionary development. When I am at the helm of a company or a development department, big or small, I don't allow others to dictate my schedule or my ability to make great software. I have been quite lucky, maybe, that my investors and customers have very much appreciated, and paid for, my approach.
It's less unfortunate in the startup world where a rainbow chasing deathmarch has at least a theoretical possibility of ending at a pot of gold. It's the deathmarch on the corporate culture treadmill where the carrot is climbing the ladder at best and keeping your health insurance more typically that really sucks.
On the other hand, a big push can be worthwhile when the timing of milestones is outside your control. Sometimes a December 26th ship date might as well be November 1, next year. Likewise, ramen is cheap but not endless and the pace at which leases burn through capital is calendar days not hours worked. The alternative isn't irrational.
I'd even go so far as to say that there is a certain buzz that comes from the occasional all-nighter...always 8-5 is the life of a shoe clerk. None of which is to suggest that balance isn't good and a worthwhile pursuit, but if the muse never visits, it's just a job not art.
Comments
I find it quite interesting how many times we hear stories like this about "cowboy" startup engineers. I subscribe to an XP (Extreme Programming) methodology which includes things like TDD, DevOps, and Pairing. I have done this at both existing large companies as well as tiny startups where I was engineer #1 or co-founder (of course, pairing started with engineer #2 ;)).
When people ask me later, how could you do all of that and still run a lean, agile startup environment I always wonder "how could I have been lean and agile without it?!"
Is testing really all that hard? No, I am well versed in testing and pretty good at it. It doesn't get in the way of my process and does help with my design.
Is pairing really restrictive? No, it's liberating! I get to work hand in hand with another engineer to get ideas out quickly, tackle bugs fast, and stay focused.
Is DevOps really a huge problem? It sure is nice to know, early in the development of a new product, that I can deploy RIGHT NOW and continually and have continuous integration and test coverage. There is a lot of value in that.
Do all of these things slow me down? I don't think so, if anything building a new product or company isn't a sprint, it's a marathon.
Now of course the opposite to all of these point are:
Adding tests later is really hard. So is removing technical debt. That hurts, a lot. A newly formed companies can't always cross that chasm.
Multiple engineers all trying to solve big problems without communication can lead to architectural and engineering issues down the road. These are hard to solve. Pairing sure helps with that.
If you can't deploy, redeploy, or move your installation easily, that is a risk to your entire business.
One added benefit of not being a cowboy (outside of your technical debt not biting you later) is in the financing and acquisition discussions become a lot more fun and lucrative. A number of Angel and VC organizations are becoming extremely tech-savy. They want to know if you have test coverage. They want to know that one day your servers won't go down and you won't be spending two weeks trying to remember how to get your entire environment configured. They want to know that their money will be placed in a great investment. These disciplined principles of development go a long way towards showing them that they will meet that goal.
Extreme programming also includes work weeks approaching forty hours...it's about people after all. That sort of approach to work-life balance isn't really to the burn the candle at both ends and the middle rocket fuelled startup aesthetic.
That's not to say that there aren't sound practices there that can be applied to a startup, but XP comes out of the world of consulting where there are clients to prioritize features and decide when enough value has been created to pull the plug on the iterations. So there is a bit of an impedance mismatch between the technique and the brutal reality of going all in for several years.
You are right about the fact that XP pushes for (and should achieve!) a 40 hour week. Again I think it's unfortunate that in the start up world we have thrown out work life balance. As if working 16 hours a day, 7 days a week is a reality that is necessary for a successful start up. I disagree. My two start ups were both quite successful without having to work people more than 40 hours because we had good principles.
We realized very early on that we honestly didn't get a huge amount of value out of the hours after 40. Why do start ups work late into the night? To deploy a feature that is having trouble? Continuous integration and deployment help with that. Adding a new amazing feature that has to be in by morning? When you have a prioritized backlog of features you can tell potential investors or customers when something will be done and they can schedule around that. No need to work until 4am to present at 8am.
I guess I am very against reactionary development. When I am at the helm of a company or a development department, big or small, I don't allow others to dictate my schedule or my ability to make great software. I have been quite lucky, maybe, that my investors and customers have very much appreciated, and paid for, my approach.
It's less unfortunate in the startup world where a rainbow chasing deathmarch has at least a theoretical possibility of ending at a pot of gold. It's the deathmarch on the corporate culture treadmill where the carrot is climbing the ladder at best and keeping your health insurance more typically that really sucks.
On the other hand, a big push can be worthwhile when the timing of milestones is outside your control. Sometimes a December 26th ship date might as well be November 1, next year. Likewise, ramen is cheap but not endless and the pace at which leases burn through capital is calendar days not hours worked. The alternative isn't irrational.
I'd even go so far as to say that there is a certain buzz that comes from the occasional all-nighter...always 8-5 is the life of a shoe clerk. None of which is to suggest that balance isn't good and a worthwhile pursuit, but if the muse never visits, it's just a job not art.