The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Software Review - What questions should I ask?

I've been asked by my employer to sit in on a software demo. 

The software is not entirely complete, and the client is looking to us to determine what needs to be completed to get the product to market.  Our company will probably take over the development from a third party.  Down the road we'll probably create a web-based version of the application as well which can be built different if necessary.

In the mean time, what sort of questions should I be asking about the software to ensure the client can get it to market?

Some questions I've already thought of, which you may find familiar:
* Is there a spec?
* Is the spec up to date?
* Are there unit tests?
* Is there an open-issue database?
y0mbo Send private email
Wednesday, February 08, 2006
 
 
* What other similar programs have you shipped? (Similar in scope, domain, technology, etc.)
* What's your policy on code reviews?
Exception Guy Send private email
Wednesday, February 08, 2006
 
 
I'm confused.

Are you looking to purchase the assets of the "third company" and continue development of the software as if it were your own?

Is that company hoping to hire you (in a sense) to act as a subject matter expert and help polish the product?

Or are you planning to develop a parallel web-based version of their product and you want to synchronize your efforts with theirs (you develop the same functionality)?

Speaking as a programmer, your questions are a very good place to start.

"In the mean time, what sort of questions should I be asking about the software to ensure the client can get it to market?" sounds more like a business question and probably needs to include things like schedule, staffing resources, development platform, target platform, technical writing support and even whether any specialized knowledge is required (such as familiarity with the field).

I think you're on the right path, but considering that software demos are typically one-two hours long, you may want to check with your boss and confirm what to focus on.
TheDavid
Wednesday, February 08, 2006
 
 
Sorry, I wasn't clear.

Our client has purchased a third party software developer and the product they are developing.

We are coming in at the client's request to do an evaluation to see what remains to be developed in order to ship.

The client will use us to finish the development of the application and for any new development.

The client already has support and training people ready for when it ships.  We would just do the programming.  So my questions would be about the technical aspects.
y0mbo Send private email
Wednesday, February 08, 2006
 
 
Ask to see some code. They should allow you to pick an arbitrary number of source modules and let you look through them. They don't need to hand you the entire application.

Look very carefully at how the application is architected. If you see a lot of business logic, state controls, and UI scripting all lumped together then you should take that as a huge warning sign.
anon
Wednesday, February 08, 2006
 
 
I would also want to see a detailed schedule that's tied into the functional specs (a question you already noted); do you need to complete task A by tomorrow and task B by a month from now?

It sounds like the original programming team ran into a problem and is not expected to solve that problem in time. As anon hinted at, the code may be no good. Or it may be the schedule is unrealistic.

A followup question might be, what build tools are they using? Can you simply just "insert" the new code, or do you also have to source control it, do the builds and distribute it to QA? Is there a bug tracking system?

Basically, find out why the client is dumping the original team and asking you to take over the work (but in a polite way).
TheDavid
Wednesday, February 08, 2006
 
 
Your ability to continue the development depends on what has been done, and quality of what has been done. Existing source code quality is important thing to catch up the development.

One of things I'm looking for doing code review is comments! Good comments improve code quality alot. I even wrote an article on this subject.

Also you can find some automated tools which will take the source and show you some code metrics or QA audit. findbugs.sourceforge.net is one example for Java.

You will have some pretty objective numbers with them.

Denis Krukovsky
http://write-software.blogspot.com/
http://dkrukovsky.blogspot.com/
Denis Krukovsky Send private email
Wednesday, February 08, 2006
 
 
When looking over the code, I would follow a vertical slice through the source.  Starting with "The user selects to update a Widget.  Let's follow it down to the database and back again"

That should give you a good idea of the architecture, error handling, state of the codebase, etc.
example Send private email
Wednesday, February 08, 2006
 
 
All of this excellent advice sounds to "close to the metal" to me. I always start any process that needs to understand an application with a thorough undestanding of the business objectives. How will this be special, how will it differentaite itself from the competition, who are the users, what are their skills, what are the user's aspirations, etc.?

When some of these questions have been answered it might be possible to evaluate how near the "product" is to market and even if the existing system design actually matches the requirement - oh yes, then take a look at the code execution.

Sounds an interesting session anyway - have fun.
Mike Griffiths Send private email
Wednesday, February 08, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz