I’m writing this from a vacation spot where I thought I had spent almost exactly zero time thinking about my day job.
This is good and a thing we should all do far more often.
I started the day with nothing to do and nowhere in particular that I had to be. So my wife and I took a cooking course with Sous Chef Scott and learned a few simple dishes that were just stunning in taste, presentation and simplicity. Scott is a really nice and laid back guy. We asked all kinds of questions and he answered each of them with a story of his experiences.
Then I wondered around and snapped pictures and I realized how much I enjoy taking pictures.
The reason I love photography is pretty simple. While I love creating things, creating things inevitably draws comments and critique, even when you are not asking for any. The pictures I take are for me. I don’t think I could ever be a professional photographer, aside from not having the skills to be one, but also because when you get paid, you are told which pictures to take. For me, that removes the art and love that goes into composing a compelling photograph.
I have taken photographs that really move me. At some level, I hope you enjoy them too, but that has never been the point of why I love one picture over another. I love them because of their meaning to me. You could say that I should have used flash, or that I pushed the color of a picture too far, and that’s fine.
However, at no time would your comment make me feel guilty for not getting it right. Nor would it affect how I feel about that particular shot. I’d keep it mind for the future, because really, that’s all I can do when it comes to a picture that is already taken, no?
Which brings me to software development. I guess I was thinking about it all along.
Since the last I posted, we launched a major system, in some ways a rewrite of an existing system, in other ways something totally new; which made things complex and had overlapping domain terminology and forced us to make difficult decisions. The requirement gathering was painful because things changed a million times, and we often over-engineered parts of the system because we knew features would be coming soon enough that we would need to account for. Why not build some of that plumbing now? We worked hard and at the end, we were very much red-lining as a team.
We were death marching.
Then we launched and things calmed down and changed. We re-gelled. We had a minimal number of issues crop up, all of which were solved within hours of finding them. It was a success, but, like I said, it wasn’t easy and we certainly didn’t do everything “by the book”.
I’m quite sure we will have disappointed several industry pundits by not following their one true way to getting things done. They would swing their one true sledgehammer upon us with impunity.
In software, we are creating, much like a photograph. People would like to think there is a great amount of science or engineering that goes into it, but really, at the heart of any software project is a need associated with people, and those people are the very reason that science and engineering are a small part of what goes into a real-world software startup project. When we start, we don’t know how big the bridge span is and we certainly don’t know if the bridge needs to support horses, cars or tractor trailers, let alone how many at a given time. Over the span of the project, we will figure those things out and there are certainly ways of coming to those knowledge bits earlier rather than later.
Yet the sledgehammer that my favorite soapbox hero is swinging is likely not a big part of our successes in this project. Using x technology didn’t solve people problems. Going to the cloud didn’t either. A relational database, NHibernate, or otherwise didn’t solve it. Tests, pairing, and readable code were certainly good things that we did on this project, but I noticed that the difference these items made were not obvious. We did them where they made sense. We did not do them where we agreed they were not needed.
To be perfectly clear and precise, sledgehammer topics are ones where x declares that you must do y in order to be professional, successful or likewise. You simply must do x 100 percent, 100 percent of the time!
I do actually wish some of these things were true, but the fact is that we do not live in a black and white world, foremost because at the heart of software is people, and people will always be that unknown factor. Often overlooked is the simple fact that software development rarely controls a business singlehandedly, and the business wields software like a tool, as it probably should.
For us, we wound up not having 100% unit test coverage; but we have a lot of integration tests. We didn’t pair on a lot of things, because there was just too much to get done. We’re working on going back through things after the fact and it seems fine so far. The sledgehammer might disagree. It will bite you in the future! You’ll slow down! You’ll start finding bugs too late! It won’t scale! We haven’t found any of these to be true at all. In fact, things are speeding up and the code changes have been easy refactors. We release daily and customer feedback has been good.