Saturday, February 28, 2009

Bosses and your approach to Agile

For me the hardest part of Agile by far is getting bosses to understand what it is, why it matters, why what they're doing now is harder than it needs to be, and why what they're doing now is causing the problems they're seeing.

There are a few reasons I've observed and you may or may not run into that I think make this difficult.
  1. Developers tend to talk over "normal" people's heads. I struggle with this and I didn't even own a computer till I was 23, so in theory I should understand the non-technical perspective better. It's just ultimately VERY hard to take a technical and very detailed issue and bring it down to simpler terms and levels.
  2. Bosses that compartmentalize software they buy and software their employees build as entirely different species. If they buy software and it doesn't behave as they expect they'll stop using it, ask for their money back or raise unholy hell. If they spend 50k in man hours for in house work they can sometimes accept it breaking on its very basic designed functionality. I've seen software like that praised because it delivered business value, even if it did so at an excessive unnecessary cost. This ends up you'd think working in our favor, except inevitably when going Agile we have a TON of software to maintain, and none of it is maintainable. This stacks the deck against going agile in so many ways that I'll leave it for a dedicated blog post.
  3. Bosses assume that developers are not able to understand business value. This one has been a huge problem for me. I go out of my way to deliver business value first and foremost, I was a successful manager before I was a software developer. However, generally speaking bosses are correct into thinking this about us a developers, which I'll cover later in another blog post. Needless to say it's blunts our effectiveness at proposing solutions.
  4. Our industry is filled with people that don't deliver what they say. Sometimes it's us just overshooting our goal. Sometimes it's developers who just want to look better than they are and stretch the truth . Finally, sometimes it's people that just are flat out interested in taking the money and running (subtle distinction to others which one of the three types you are). Regardless, some bosses have been burned so much they assume everything is a lie and they've made up their mind when they walk in the room.
  5. Some bosses take a lot of pride in having a big hand in implementation details. Now while this can easily help you once you have agile working if they are interested in helping you produce software that has lots of feedback. However, if your boss is this way, he's probably a former developer in a time far far away, and absolutely convinced about how a software project should be implemented (and assumes that the way they did it then was perfect despite the problems that all projects inevitably have).
There are certainly more, and if anyone wants to share please do. In future blog posts I'll go through these one by one about what problems they cause and hopefully I can work through how to conquer these challenges in the future.

Wednesday, February 18, 2009

"Do I Care" and "It Depends"

Between my time talking to Agile Joe when my bank hired him and Jimmy Bogard in the last Virtual Alt.net meeting, I now have two new guiding principles to most development tasks.

Do I Care?

  • Should you unit test this code? Do I care about that code? Do I care if I change things later and this is not tested?
  • Should I write this Documentation? Do I care about the docs and what they say? Do I care if I can't remember what I did?
  • Should I delete this code? Do I care about it anymore? Does it do anything for me now?
  • Should I follow SOLID principles here? Is the work needed worth it for the payoff?
All of these questions may or may not be yes or no to "Do I Care?". So how do you know if you care or not..this dovetails nicely with "It Depends".

Like it or not one of our primary jobs is too manage tradeoffs. In one case we hamstring ourselves with too much work for little benefit in another we do not do nearly enough "housekeeping work" to make our code manageable.

Full on SOLID on an application you're building for a day and then going to throw away? I'd hope you say "No I Don't Care About SOLID where it causes me more work", an app that will take 2 months to build...if you don't care, make sure it's only the first couple of days and not when it's too late.

Bob Martin focuses on the "last responsible moment" i really always liked that and all but I feel like "Do I Care" maybe appeals in a more plain spoken way. I only follow "good patterns and design" when I start caring, otherwise I fall into the trap of forgetting why i do these things in the first place.

Monday, February 16, 2009

What to work on

Been quite busy with work for a couple of weeks, but as that is winding down a bit. I think I need another oss project to focus on. Pinsor needs one decent rewrite for clarity, and then some basic feature support and it'll need actual usage to warrant more changes.

Been thinking about what I should work on next?
  • Job scheduler ( some reason always loved these kind of projects, and could use pinsor on it)
  • Scrum project manager web app (would have to actually get comfy with pylons/tg/django)
  • BDD framework in either C#, python or start contribing to spectre in boo.