Thursday, November 12, 2009

Keys to a Successful Development Project

I was reading an article about startups recently and the author claimed that success was not due to one big thing, but a lot of little things. We had a business coach a few years back that said the same thing – when we reach the level of success we’re aiming for we won’t be able to look back and put our finger on one thing, but instead, we’ll see it was many little things contributing and working together.

It got me thinking – is that true of software projects as well? Probably. This may be one of those universal laws like the Pareto principal (aka the 80-20 rule), that seems to apply to everything.

Is there one thing, one big key that will make a project successful? If I had to pick only one, I would say it would be the team, but is that enough? I don’t think so. Even the greatest team can’t be successful with a lousy idea, bad requirements or no funding. Sure they may be able to get something out the door, but will it sell in the marketplace? Will it really meet a need? Probably not.

Ok, so I guess we’ve established that I don’t believe in “silver bullets”. So back to the original premise – what are all those little things? Well certainly the team, but what about tools, processes, appropriate budgets, management support, a great idea, customer need, stellar marketing, support, sales, etc……

It really does take a village!

Monday, November 2, 2009

What does a software developer need to begin design?

Too many projects begin without even a hint of a written understanding about what is to be built. Unfortunately many of us have been there and lived through the pain of redesign and project slippage. At the other end of the spectrum some write suffocatingly detailed Requirements Documents. Masterpieces of literature that developers and managers don’t actually understand if they read it all! As in the case of no written requirements, the project usually ends up in the same predicament --- redesign, rework and missed opportunity.

In my experience developing embedded systems or software applications the big picture requirements must be spelled out. They should contain at a minimum the following: performance goals, safety factors, Human-Machine Interaction, testability, external interfaces, deployment, and target cost for hardware designs.

Defining the products requirements does not have to take a very long time. I find that in most cases this phase should take on average 2 - 4 weeks working collaboratively with the major stake holders.

The important point to keep in mind is that the requirements document must be be in a form that is easily understood by the technical team as well as non-technical management. Keep it as jargon free as possible. Define all terms.


For example, an excellent way to define the user interface level independent of the actual technology used are pictures. It is more effective to draw a screen or touch panel then to try to describe it. Even more effective, use a rapid prototype application to create a demonstration of application. This is the most effective way to create a common vision between developer and manager of the look and feel of the resultant product. Be sure to include one or more block diagrams to illustrate the system and interfaces.

The next time you start a project please don’t settle for 10 bullets on a napkin!

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.

Friday, September 11, 2009

Getting a Job as an Engineer or Programmer

I know a lot of people that have been out of work for a long time.  Most of them are continuing the battle.  So what can they do to increase their chances?  Besides the obvious (networking, personal introductions, etc) there are ways candidates can stand out from the crowd even when they don’t have a personal connection in the hiring company.

First some basics, I am amazed at how many candidates don’t return phone calls, or when they do they’re rude, disinterested or worse.  I’ve had phone conversations with your typically “crusty” engineer, and I even had a candidate recently swear at me.  Actually, not just once, but a long angry “F-bomb” laced tirade.  I understand he was frustrated, but calling me names did not make me inclined to help him out.

Ok, so assuming you have some basic common sense and social skills what can you do to stand out?  Do a little research – check out my company.  At least know what we do, better yet, have some relevant questions.  Next, have some ideas how you can add value to my company.  Interviewers need to figure this out – make it easy on us.  If you have prior experience in my industry, highlight it.  Don’t just assume that because it’s on your resume it will be obvious.  Finally, tell me something about yourself that differentiates you.  Please, please, don’t tell me you have good people skills or are a self starter. It may well be true, and it may be very important for the job, but it’s so cliché, it’s meaningless.

And for extra credit?  Go above and beyond and do some more research.  Find someone in the company or a former employee (LinkedIn is a great resource for this) and get more info about the culture, and what the job entails, and then tell me how you specifically, with your unique background and skill set can help make my company more successful.  The more specific the better, and if you can tell me how you’ve done this in the past, even better!

Good luck, and keep the faith!

Friday, August 7, 2009

Hiring engineers now is easy, right?

Wrong!  I’ve run across quite a few people in the past year that have assumed that’s the case, but have found out differently.  Hiring top software programmers and hardware engineers is always a challenge.  Having piles and piles and piles of resumes does NOT make it any easier.

So what’s a hiring manager to do?  Well, the last hire I did for myself (as opposed to the ones that I help our clients with) I had four very clear objective criteria.

1)      The candidate had to have a Bachelors’ degree

2)      The candidate had to have experience with a specific program

3)      The candidate had to have at least 2 years professional experience

4)      The candidate did not require H1-b sponsorship

One of our clients is doing this now with good success.

Now, I know you can make valid arguments against any of those hard and fast rules.  Some of the smartest people I know don’t have college degrees.  In different times I might have made that argument myself (might be good idea for a blog entry next year), but you need some way to get through hundreds of resumes a week.  The nice thing about objective criteria is that a hiring manager can get help – someone to prescreen for him.  So what are your deal breakers?  Knowing that going in will make hiring in these times much easier.

I’m sure all you job seekers out there are saying “That’s not fair!”  You’re right, but as my mother always said, Life’s not always fair.  So what’s a job seeker to do?  Well, I need something to write about next week…