Starting a new gig

A few months ago, Jeffrey Palermo approached me at an AgileATX meeting to join him at Headspring Systems.  After much cajoling and intimidation (Jeff’s a big guy), I accepted the offer, and today I started my new job.  Headspring Systems offered me a great opportunity to help customers succeed, where success might not mean just developing whatever requirement the customer throws at me.

Headspring is a .NET shop that uses ALT.NET/Agile principles to deliver solutions.  That means this blog is going to start seeing a lot more NHibernate, StructureMap, Domain-Driven Design, Behavior-Driven Design, design patterns, ASP.NET MVC, and a whole lot less on legacy code.  I love the Michael Feathers, but legacy code is a challenge I like to tackle where there is a commitment to pay down the technical debt.  We’re also committed not create more legacy code, which is also a refreshing philosophy.

Also, it’s my first consulting experience, so any advice is welcome :) (e.g. customer is always wrong, etc.).

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Wow, congratulations, but sorry to lose you from our gang. I hope your new gig is a ton of fun.

  • Congrats on the new gig!

  • > but legacy code is a challenge I like to tackle where there is a commitment to pay down the technical debt.

    Wow, couldn’t have stated my current feelings on that better myself. Congrats Jimmy!

  • Awesome stuff! Congrats. I wish you and Jeffrey luck. Sounds like an awesome gig!

  • Stop stop you are making all of us jealous and I will have to hack you box and destroy you code out of spite. LOL Congratulations!

  • A Former Consultant

    Advice as a consultant? Yeah, here’s some: Your clients are going to expect you to solve business problems, not technical ones. They won’t care about technical debt unless it’s becoming a business problem. And most of them won’t ever see it as a business problem. So if you think you’re going to go on a billable gig and have this Agile Utopia every time, you’re in for some harsh reckoning I’m afraid.

  • Glenn Burnside

    So given this change, maybe you need to revisit your “About Me” blurb…

  • Joe, what @A Former Consultant is trying to say is that you should stop worrying about personal integrity and doing the job right and just perpetuate all the problems in software by doing whatever you’re told, no matter how wrong and harmful it’ll be to the customer because *shrug shoulders* that’s what they asked for!

    “I Told you So”-driven development has been proven effective time and time again at producing recurring revenue for consultants (as A Former Consultant clearly points out). Why do anything different!

    Customers EXPECT software to fail, that’s why they hire consultants!

    Please stop making software and software process better, because you’re making it harder for all us “Former Consultants” to keep bilking our customer by not improving anything and letting the blind lead the blind!

    Just stop! And tell that Jeffrey Palermo guy to stop too. All these “talks” and ‘screencasts” and attempts to “raise the bar” are just harming the classic software blik– I mean consulting model!

  • @Chad,
    Wow. As a “current consultant” working for a firm that seems to care very *little* about technical debt, I couldn’t have put it better myself. It’s so frustrating to hear stuff said like what “former consultant” said in his comment. I hear it all the time. What’s sad is that sometimes I think I take my job as a consultant too seriously because I actually *care* about the QUALITY of software being delivered to my clients.

    The fact that clients are just used to poor quality and lots of follow up maintenance contracts because of poorly designed software, doesn’t mean consultants should just keep the “status quo”.

  • I think what Chad Myers says can best be summed up thusly:

    “Ignorance is billable.”

  • @A former consultant

    Luckily, we have a CTO that can explain _very_ clearly to clients _exactly_ what our Agile processes bring to the table that other technically-oriented consultants do not.  Namely, other folks might be able to deliver what the BDUF requirements say, but through our iterative process, we’re able to deliver solutions the customer wants and needs, not what they believe they wanted at the beginning of the project.

    Because guess what, as soon as they see working software in 1-2 weeks, what they want will change.  Agile isn’t something we sell.

    We sell better and more accurate delivery through Agile.  We sell better maintainability through automation, CI and testing, so next iteration’s features are easier to deliver.  We sell high levels of customer involvement and transparency through Whole Team.

    Technical debt _is_ a business problem, and I can explain in ways to make them understand that.  The easiest way to deal with technical debt is to not let it accumulate in the first place.

    We don’t ask the customer _how_ they would like us to deliver.  I don’t tell a carpenter _how_ to build furniture, I tell them _what_ furniture I want.  I then communicate with the carpenter to come up with a solution that will fit my needs.  I don’t always know my needs, so the carpenter’s expertise will help guide details.

    And if the customer doesn’t want what we sell, we’ll move on.