When Is Software Ready to Demo?

During the development of custom software applications I am often confronted by the question of when to demonstrate software that is still under development.

The fear of every developer is to allow individuals to interact with the software before it is "ready." Of course, defining "ready" is the challenge--but so is defining who is giving the demo, its purpose and the composition of the audience.

In the early stage of development, as a developer or technical lead, I am the one pushing for a demo intended to uncover questionable areas of the requirements definition or technology issues as early in the development process as possible. (The actual software may very well be throwaway code.) For this to be effective, the test application should be created rapidly with a single focus (e.g. illustrate performance, screen layout, work-flow, or even error handling). The main idea is to eliminate as many unknowns as possible and to throw light upon aspects of a complex system as early as possible. We want to avoid going down a path too far, only to find we are proceeding in the wrong direction. These demos are typically oriented for technical people on the team as well as stakeholders.

The next opportunity for a demo is the more traditional usage. At this stage of development, the application is not complete but major functions are implemented and tested. The purpose is to measure the applications performance against requirements in a controlled setting. One example is to gain feedback observing typical users, where feasible, interacting with the application. Are there confusing areas? What happens when a mistake is made?

Another effective demo is to stress-test the application. This can be done by scripting data entry or transactions for example. Allow the application to run for an extended period of time and measure performance. Now I am looking to expose areas of weakness and potential bottlenecks that must be addressed.

Finally the software is code complete, tested and ready for release. It is safe to demo at a trade show and in front of potential customers. In fact, at this stage, the software is ready for beta site deployment.

-Gary

To Reuse Firmware or Not to Reuse

Sometimes on new embedded development projects I am presented the option of repurposing firmware that has already been developed for the intended platform.

At first glance, repurposing seems a no-brainer because of its potential for saving time and effort, but a closer look at the risks involved paints a different picture.

Risks of repurposing firmware include unknown bugs, uncorrected known bugs, poor programming practices, and "fragile" software that becomes unstable after change. And sometimes even though the software is well-written it just doesn't achieve its intended purpose.

Here are some criteria I find helpful when evaluating if I can reuse a firmware code base:

• Documentation: Does it exist and is it current? (Specifically, I ask for design documentation and test procedures.)


• Understandability: Simply read through the source code. Does the style and format conform to your standards?


• Testability: Has the code been unit tested? Can you duplicate the results?


• Availability of original developer: Can you contact the programmer(s) should you run into problems?


• Version and source control: Is the software under active management and control?

Unfortunately I have not found a failproof system to make this decision. However if more than half of the above points are answered in the negative I choose to start from scratch.

 

Do Business and Engineering Get Along?

A comment from David B on our recent blogpost on process fanatics got me thinking. He points out that there is often a “dichotomy in point of view and approach between technically focused people and business solutions folk. The more effectively you can get them to ‘walk a mile in each other's shoes’, so to speak, the better the odds of developing technical software solutions that meet--or even exceed--the needs of the end user.” So true!

I’ve been on both sides, and this is definitely apparent. Unfortunately, the solution is not as clear, but I think a respect for what each group brings to the table is a great place to start.

Business people think that engineers often look down on them because they don’t understand all the things the engineers do, and this makes them “stupid,” though in reality, they bring a lot to the table. Who would take that cool technology and turn it into dollars to pay those engineering salaries without all the other functions of a business?

On the other side, business people often think that engineers are putting up unnecessary roadblocks regarding what they can deliver and when. It’s easy to ask for the moon, but it’s not so easy to deliver it. Understanding a bit about the technical challenges of developing a new product would go a long way.

Do any of you work in a company where this problem has been solved or somewhat alleviated? What did you do?

-Judi

Software Design Considerations

In continuation of my content series on software development process I’ve added a video on software design. It talks about important aspects to consider and also issues about designing in an agile methodology.

You can watch it at http://www.youtube.com/watch?v=z5Xf3EO02E0

Also, I'll be recording some new videos soon. Feel free to suggest a topic you're interested in. Thanks!

Software Process Improvement Consulting

In 2005, I joined Advanced Decisions to establish a Software Process Improvement practice within the company. Well, long story short, I got busy with our core business of software and hardware product development and we never formally developed that practice. The interesting thing is that we seem to provide consulting on Software Process and SDLC as part of many of our engagements anyway.

The most obvious example is our work with start-ups. We typically are engaged to develop their product, but often wind up developing their process, their team, and even on occasion aspects of their business. With our larger clients we develop good quality documentation that’s often used as an example of what to develop in the future. Even with our prospects, we ask them enough questions about how they are developing their products to get them thinking.

It just goes to show, the outcome of a goal or desire may not always look like you expect.