ReWork

I've been reading REWORK over the last couple of days, an ideal book for odd moments which don't allow a train of thought to build up. I've had the pleasure of using 37signals' BaseCamp in other projects, so I'm predisposed to liking what they do. The book is a good articulation of "do one thing, do it well, do it to please some people, and just get on and do it".


Much of the advice I'm kind-of already doing (small, simple, what you want...) although the project I'm writing about here contrasts a fair bit with what I'm doing most of the time. I'm debt-averse, so the plan-Z approach to outside funding and spending ahead of earning rings true near the start. A few points have made me think, many have made me smile, one has added a task to my backlog, and it pushed me into starting this blog this week. That's not a bad return for a light read. At the same time, I have a critical eye, for instance:
If we all develop the businesses we want ourselves, who develops for those that can't do it themselves? Even if we develop for ourselves, is it worth pausing to wonder if some other bunch of people have almost overlapping needs that we might consider?
Scale and longevity will cost less to fix now than when problems occur. If success involves ten thousand customers or products that last two years then the design probably ought to consider how that will work and how a first-pass "get something out there" implementation will be swapped for the scalable, durable version when the first version starts to look tatty. Design is cheap compared to implementation and might not cost all that much, so there's a middle ground between "do it all now" and "worry about it later". I'm an engineer, there's always a trade-off! Of course, if ten thousand customers is a made up problem then move along with what works.
In sum: Lots of good sense, some of it common but much of it apparently not-so-common. Confirmation, which is always nice to have, that lean and rooted in people are acceptable ways to succeed in business.