Would you like to know how I do things?

Over the years, as I speak to other developers, or give presentations at events, I always end up with a lot of questions about “How do you…[x]?”

It occurs to me that there’s an awful lot of information out there about the ideal ways to do things, or about how things should be done, or even personal stories about how things are done, but there’s not a ton of people out there saying “This is how all this stuff works on my team, end to end, top to bottom”

Further, there always seems to be a focus on what we’re doing *now* with a lack of the context of how we got here and how we plan to go forward. This is how I do planning today. This is how I do testing today. This is how we do pairing today. The big questions from those that want to look at implementing these things are always in the form of “Ok, but how did you get there? How did you sell it to management? How did you get your team to buy in?”

Last year at KaizenConf the Dovetail team led by Chad and Jeremy did a workshop that they called, tongue-in-cheek, “Opening the Kimono”, in which they talked about how they are doing things with MVC at Dovetail, how they came to the decisions they came to, and how they have evolved what they are doing. They opened Visual Studio and showed their actual code. They walked through their process. It was, in its own way, beautiful, and it was a wildly popular session.

So I’ve gotten enough questions from enough people about how my team works, and how it got to where it is, that I think maybe it’s time that I open the kimono a bit and share.

The question to you, dear reader, is would this interest you? Would you like to know things like how we handle quality, how we implemented pairing, how we plan work, in short, how we run the team and build software?

Now the caveat here is that I’m just one guy, doing things on one team, in one company. My way is not going to be the way that works for everyone, and I’m willing to accept that I do a lot of stuff *wrong*. Hell, I know I do, because I have ample areas in which I can improve. But if real descriptions of how I do things and the journey to get there will be helpful to the community, then I’m willing to lay it bare.

So, if this interests you, leave a comment, or send an email, or hit me on Twitter, and let me know. If you have specific things you’d like to see me address, include them. If you think this would have no value, then let me know that too. I’d hate to engage in so much navel gazing if nobody will get anything from it.

Technorati Tags:
, , ,

About Scott Reynolds

Scott C. Reynolds is a developer with over a decade of experience creating enterprise solutions, primarily in healthcare and biotechnology. He is passionate about the art and craft of applying software solutions to business problems. He is a frequent speaker and participant of community events nationwide.
This entry was posted in community, management. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to Would you like to know how I do things?

  1. If you are willing to outline those processes, I find such accounts very interesting. How a team works, how they deal with the daily churn of meeting specs, keeping up quality and meeting the deadlines is something that can go badly wrong or make you a happy and highly productive guy. So, by all means, go ahead :)

  2. Chris Hilton says:

    I’ve been tossing around a similar idea around how our continuous integration process has been evolving at Zilliant. In many ways it’s ugly, far from ideal, not what I would recommend to anyone…and it’s showing a lot of benefits, including increased interest in adopting other agile methodologies.

    Some specific “How do you”s I would be interested in that may or may not apply:
    1. How do you unit test your enterprise apps? With or without database/app server, other specific problems beyond standard unit tests.
    2. How do you unit test your GUIs (and keep it fast)? Web client GUIs obviously, but a Swing client GUI would be especially interesting.
    3. How do you enforce/encourage good unit tests are written?
    4. How do you design your enterprise apps to accommodate testing?
    5. How does your process work from day-to-day for your average developer? How many times a day do they code/test/check-in?
    6. How do you produce release artifacts? From your CI process or a separate release build?

    Hopefully that’ll give you some ideas.

  3. Mark Needham says:

    That’s Definitely sounds like that’d be something interesting to read so yeah +1 from me.

  4. JeronimoBlack says:

    Hi. I would like to ask anybody about problem with dynamic entities. I mean, that user is able to add an property to an Entity. And next month to search for the entities with some value in the extended property. Did you do something similar?

  5. Simon Martin says:

    I would love to learn about how you do things + 1 from me too.

  6. If I actually read you blog, this would interesting immensely. You know, if I read your blog.