Friday, October 23, 2009

Feast or Famine in Software Development Organizations?

In so many areas of my life I go thru these cycles of feast or famine – social engagements, work load, car problems, what have you. I either have lots or none, or is that just my perception?

There’s one area that I can think of in which I’ve never had this problem – the software development organizations I’ve been a part of. Sure, we’ve had that with bugs, or turnover, but never, ever, ever workload. There was ALWAYS more than enough work to do. Maybe it’s just the nature of the beast – companies always want to improve their products and there are a wealth of ideas on how to do that. It’s also a positive thing. I love being busy, and if a company can not keep it’s developers busy, why does it need them?

The downside however can be a feeling of overwhelm, or inefficiencies, or continual long, long weeks. What kinds of things can we do to smooth this out a bit, or at least mitigate the negatives? I have some ideas:

1) Prioritization – so many organizations are SO bad at this. The priority is the priority of the moment, based on the loudest customer, one data point, or the whim of an executive. A well thought out prioritization can allow your development teams to get more done, just by finishing what they’re already working on. I’m not saying it should never change, but it certainly should change less frequently than you change your clothes.
2) Focus – knowing the big picture will help with number 1, as well as with coherency of design and team morale. If you’re building something to do x, don’t try to do y. Pick one thing (at least to start) and do it exceptionally well
3) Learn to say “No” – I find that people (not just in development organizations) spend an inordinate amount of time exploring roads not taken, as in “maybe we should have done x”. I once heard a speaker call this “Killing the un-chosen alternative.” I like that, and not because I’m violent – I’m not. I like it because it allows you to devote 110% of your attention to being successful on the path chosen and stop second-guessing yourself, a time wasting distraction if there ever was one.

I for one hope there isn’t a famine of new product ideas or developers to carry them out. Let’s just try to do it sanely.

Friday, October 16, 2009

Self-regulation in Software Development

Senia Maymin (I can’t link to her website for some reason – I’ll update this when I can) has written a bunch about a concept called Self-Regulation. This concept fascinates me. It’s one of those things that’s simple – particularly to understand, but certainly not easy. It’s the skill that you use to do the things you need to or should do. The idea is that self-regulation is like a muscle and the more you use it (in any area) the stronger it gets (in every area.)

It’s easy to see how it applies to my life – go to the gym, make my sales calls, blog, etc. I always thought that once you did those things and saw the benefits, you’d do them again BECAUSE you saw the benefits, but the way she talks about it, it’s less intellectual than that. The more you do these things, the easier it is to do other things. But how does it apply to the field of Software Development?

It’s easy to see the areas where you might need self-regulation, testing, documentation, and perhaps for some, design. Does this mean that if you make yourself do a good thorough design it will be easier to make yourself do the testing or documentation? Well, it’s certainly easier to do those activities for a well designed system, but is it easier to get yourself motivated to do them? Interesting question – I really don’t know…

Friday, October 9, 2009

Partnering with other engineering firms

We’ve been interested in partnering with other engineering firms, but have never quite made it work. I’m not exactly sure why, but looking back, I’m not sure all the previous attempts have been true partnerships. We’ve been approached by a few firms recently, so it’s got me thinking about it again.

It seems like it would be a good idea. We often have consulting jobs and don’t have the right person, and occasionally we have a consultant free that may be able to do a job for another firm. In this economy, it makes sense to maximize any opportunity, and by working with other firms, you can expand your network and broaden your offerings.

So what would a perfect partner look like? Well, first of all there would be some commonalities. For example it makes more sense for us to partner with someone working in product development than say distribution. Second, there should be some extension of services. We’ve met a great mechanical design firm in the past, which could be a great potential partner. We do very little of that, and they do very little software and hardware design. Finally, there needs to be common values. We would never consider partnering with a firm that did shoddy work or engaged in unsavory (in our opinion) business practices.

I’m looking forward finding those good fits. I guess with anything, patience is key.