“If you fail to plan, you are planning to fail.” — Benjamin Franklin
Just as any software development project should have a project plan to ensure a successful project, it should also have a test plan to ensure adequate and effective verification of what is being developed, as part of the overall project quality assurance. Developing the test plan should be a collaborative effort by the project team from the start of the project, beginning with general project and testing information. The project testers should be involved from the very start.
Essential components of a test plan include the following.
It is very important for a development team, including the project testers, to understand the overall project. This sets the stage for the project, and for every testing round. (more…)
At the most basic level, all great code does what it was written to do, correctly, efficiently, and robustly. It should be as free of bugs as possible, not waste time doing its job, and handle bad input data in a reasonable way. This is pretty obvious, but there are a lot of software projects in the world that don’t do a very good job of hitting this mark. Too many software projects, after getting to this level, stop. Certainly, there are cases where that’s reasonable — perhaps for a quick bit of one-off code to convert data between two formats, the extra effort of optimizing code or catching all output errors in code might take more time than waiting for the application to complete, or to correct the erroneous output by hand.
For any real code that’s going to be used in a serious way, there are other attributes that can have a major impact on the long-term viability and health of a project.
What every client wants to know.
One of the first questions asked by nearly every client is “What will this project cost?”. It is a perfectly reasonable question. Few of us have enough money to not worry about how much a project will cost. And all clients would like to know exactly what the price will be before undertaking a project.
The most easily understood pricing model is Fixed Price.
Fixed price contracts are simple in theory. Clients tell developers exactly what they want built. Developers respond with a price. A contract is signed. At the end of the project the product is delivered and the final check is cashed. Simple, right?
Software is a Risky Business
It seems to me that if there were any logic to our language, trust would be a four letter word.
– Joel Goodson
Starting a relationship with a software development firm can be intimidating, and frankly somewhat risky. Clients need developers to understand and implement their vision quickly and thoroughly, use budget carefully, follow best practices in areas that are hard to verify, and respect confidentiality. This requires a lot of trust, and trust can be hard to come by in any new relationship.
What may be less obvious is that trust is required in both directions. Developers rely on clients to communicate their needs clearly and honestly. They need to have releases thoroughly examined, candid feedback provided, and financial matters handled responsibly. This extends beyond paying the bills; engaging in a software project requires careful planning to ensure that the project doesn’t end up underfunded and incomplete.
So how can a prospective client know that they’re making a reasonable choice in hiring a particular firm, and also that they’re prepared to hold up their end of the bargain? What follows is an overview of what one can expect to encounter in a successful collaborative development relationship.
There was a book published in 1992, when Art & Logic was in its infancy, entitled Voltaire’s Bastards. The author, John Ralston Saul, argues that Western civilization has become enslaved to reason to the detriment of our society, economy, and culture. He doesn’t argue that reason is unimportant, just that it’s one facet of thought leadership along with intuition, imagination, common sense, and morality. When reason alone is valued above the rest, decision-making suffers and poorer outcomes result.
Saul’s argument gave me a context for something I think I’ve always known intuitively: that programmers need more than high-functioning logic to be great. They also need intuition, imagination, and common sense.
It’s not your rational mind that wakes you up at 5 AM with an “ah ha” solution to whatever programming challenge was troubling you the previous day. It’s intuition. We often think of building software as a top down analytical activity – gather requirements, architect a solution, design the classes and objects, write the code etc. – but some of the best programmers infuse these activities with a surprisingly intuitive, visual approach. A close friend of mine describes “seeing” the many components of a complex system in his mind’s eye, and watching them interact in a complex dance, before he begins laying out a design on paper.