At Duck Pond, we believe in
practical software. Practical Software Practices yield
quality software results.
In the last decade, developers moved from "Waterfall" to "Extreme" and "Agile." But “Agile” often resulted in
no requirements written down. "That just slow things down," some say. We heard "We want to keep it 'flexible', to be able to adapt to last minute brilliant flashes of marketing genius".
That "may" work for the initial pass of a small development project, but not for real software
to be used by real users in the real world.
The
21st century wants and needs "Practical Software". Deliver high quality software that meets your customer's needs
for a fraction of the cost (your CEO will love that!)
Ensure cross-functional communication and collaboration with team-based, efficient processes.
Now, that's practical !
Practical Requirements Management
There is a set of software practices that are non-negotiable, and they begin with two that are requirements-related:
- #1 Written, reviewed, approved requirements
- #2 A requirements baseline, implemented with a requirements management (RM) tool
This is true regardless of size of company - start-up, mid-size, large enterprise application company.
We asked some key managers from a company used to good requirements management if they thought that requirements management was important. Their comments:
- [Development Manager]: The DOORS specs are absolutely fabulous for requirements tracking. It is a must for any software company…
- [Architect/Geek]: I think it's critical to have documented what the software is to do so the developer knows what to do and the QA team knows what to test. [Having] accountability is huge.
- [Technical Support Manager]: Without documented specs, only the developers can support the software - that's not efficient.
Practical Software Design
Software architecture projects should always aim for simplicity of design. A simple, uniform design reduces development time, improves maintainability, and makes modifications quicker and easier.
Often developers and software architects think they have an “elegant” design because they have tried to design very generically and/or very object-oriented, used a lot of open software components, and/or tried to plan for yet undefined requirements. But often the result is software that is much more complicated and bulky than needed. Over-designed, bulky software is costly to develop and maintain.
How can you tell if you truly have a good design or not? Here are the five keys to good software design:
- #1 Is there a simpler approach?
- #2 Is it customer-focused?
- #3 Is it designed for the expected user base?
- #4 Was performance considered?
- #5 Is it reliable, maintainable, supportable?
Practical Change Management
That requirements will change is a given. How you plan for and manage that change is crucial. Think about what you want to accomplish with your change management, what you want to protect yourself from, what you want to avoid, and then put in place the practice that makes sense for you.
Having a tool that will
- allow anyone to enter a change request
- maintain information associated with the change to help with its evaluation
- track the request
is a good start, but not sufficient.
You must also have a process in place to
- review and triage change requests, evaluating both their importance and impact (to schedule, ultimately)
- place the accepted requirement changes (or new requirements) into the requirement baseline for the proper release
Practical Test Management
There are some basic things you’d like to see as a result of your testing. For example, wouldn’t you like to:
- #1 Know that each requirement was tested (or what’s left to be tested)?
- #2 Understand how thoroughly the requirement was tested?
- #3 Understand what needs to be retested after changes are made or new features are added?
Customer Support
It may seem obvious, but the better the quality of the product, the lower the customer service expense.
And the high quality of the product relates to the development processes used.
In our past company, we saw the results of the practical-but-mandatory nature of our development process. And, there is a direct correlation between good-quality software and customer service expense. Duh. Yeah, I know. But this isn’t always obvious to people who should know better.
