When you develop a software product lot’s of adverse things may happen during software development  process: product idea may fail, idea is good but the feature set isn’t right, features good but software’s too buggy or not delivered at all, software’s delivered but performance is not sufficient to handle even easy user load or configuration management ain’t appropriate and you lose user data or system badly crashes but you inquire about that from TechCrunch…

There’s one very simple rule that works not just for software engineering but for the way people think and act:

If you want to be able to do something successfuly – do it frequently.

It relates to both complex tasks and tasks that you think are simple. Based on our experience for software development process, this boils down to following tips:

  • Build and deploy interim versions of your product as frequently as you can. Do it at least once per day.
  • Demonstrate new builds (“demonstrate” doesn’t mean “release”) to your customers and to the end-users. Demonstrate builds every week to the customer and arrange for demoing it to selected end-user at least once per every two-three weeks.
  • Illustrate your questions, comments, ideas using current build making your product a “communication platform”. Do the same with each software developer in the team. “Here, take a look at my monitor…” or “let’s run a WebEx session” should become neccessary daily practice.
  • Release software frequently and perform necessary software testing. New features always complicate configurations and maintenance process, so be ready. Release every 4-8 weeks.
  • Measure system performance every software development iteration (1-2 weeks) and take actions when improvement needed.
  • Look for potential technological improvements and consider options every iteration. See if you can esily migrate to a better Ajax framework or switch to different indexing model in your DB or improve your algorithms or else… this keeps the team up to innovations and really improves the product during the entire product lifecycle.
  • Business people meet up with engineering team as frequently as possible, product management, product marketing and engineering teams synchronize as much as possible.
  • Develop a habit of talking to other software development  teams, consultants, business people, even a  software programmer or a software developer. If you did find a better Ajax framework, share it with others and they will share their view with you what a good new distributed version control system they now use. Constantly give and receive back.

011_blog_best_way_to_reduce_product_development_risks_or_the_only_way_4_4_2009.png

One may say there’s considerable intersection with agile methodology. Indeed this is true for some of them. On the other other hand to avoid typical illusion, like that the team becomes agile as soon as it calls themselves an “agile team”, I just wanted to emphasize very simple but useful idea or making risk-eliminating tasks a habit for the team.
Alex Yakima
Paul is a software architect for Luminis Technologies and the author of “Building Modular Cloud Apps With OSGi”. He believes that modularity and the cloud are the two main challenges we have to deal with to bring technology to the next level, and is working on making this possible for mainstream software development. Today he is working on educational software focussed on personalised learning for high school students in the Netherlands. Paul is an active contributor on open source projects such as Amdatu, Apache ACE and Bndtools.