A Hammer on Soft Objects

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.

As it is, there really are a few things I think are maxims in software development, but they don’t swing as hard as a hammer. They’re subtle, soft and actually pretty simple. They don’t have the weight of a good profound maxim however, and perhaps that’s why people don’t use them as a weapon: Simple wins out every time If you  can’t simplify something, ask yourself if you really understand it well enough. Then reduce it again. Make it more simple. 99% of software is the maintenance and change that occurs after the first time you publish it to production. You’ll have 1000 things on your mind the next time you return to it, so keep it simple and do yourself a future favor. Low-fi first, then rough in Every time I just start coding, I stop and draw it out. I go through a lot of moleskines, but if you walk away from a conversation and you don’t draw it out, you risk the old, I thought triangle, you thought square conundrum. The Mona Lisa wasn’t painted one square at a time. Involve the customer We had so many features we fell in love with. Customers didn’t care or even notice. Some we had to get rid of and simplify in a hurry. The bottom line is in a startup, nobody’s opinion counts unless they are an actual paying customer. Communicate often, but clearly For me, morning stand-ups with the team are a must. I have to know the current status and I assume others need to know mine. Be prepared and be on point. One thing I have noticed is that when you can’t explain over IM and you jump to a call, things can become even more confusing, because people talk faster than they write. That’s the point where drawing and simplifying breaks the fog. Do it often. Trust your gut When something starts to feel heavy, or not simple, stop and regroup. When a decision starts to make you second guess things, retable the issue and make another decision. Know when you don’t know and let others know this is uncharted territory. Be honest and learn from mistakes If you’ve made a mistake, admit it and let everyone know. If you’re going to fail, fail fast and learn from it. Put something into place so that the issue cannot occur again. Ask other people when you don’t know. In the end, we built something, released and are starting the next iteration. Customers are happy. Internal teams are happy. We are learning as we go about what to build next and letting customers drive that wagon. For me personally, I’m happy that we got over a hump that was our initial launch, and I’m happy to start thinking about future features that will be really interesting to work on. Most importantly for me, and in the spirit of my epiphany post, I’m not feeling guilty about hammerish topics any longer and I simply will not do so ever again. Certainly there is always more to learn, more to apply, but it isn’t the case that one thing is going to make or break any given day, feature or project. I think I can describe it best as, while watching Chef Scott show us how to make Spätzle this morning, I remarked how it takes “a feel” to get the technique of pushing the dough correctly, and he said it just takes practice. “When you do it enough, you know when it is right and certainly when it is wrong”.  The conversation completely reminded me of something a good friend used to say to me often,  ”A good chef never needs a cookbook”. Yes, at some point you just know. You know by doing and participating. Wielding a hammer doesn’t teach people. Wielding a hammer doesn’t close the gap between not knowing and otherwise. Teach by doing. Show a good way of doing things. Be like Scott, and show this is why you do this and why you do not do that. I came to learn, please don’t hammer me. I will always try to do the same. But for now, I have to go, there are some pictures that need taking. P.S. Thanks to Ron De Las Alas, Eric Kepes and Eric Reis’ Lean Startup for the idea behind this post.