Quality seems to be something of a marmite topic, splitting people firmly into one of two camps, those that recognise quality does not happen by chance and is essential to success, and those for whom the word "quality" is used rarely, if at all, beyond the conversations that engage the paying client.
I have worked for organisations where "quality" is assumed to be present if the customer signs off the deliverables and the project was delivered on/under budget. By inference, it is clear such cultures do not value, nurture or assess quality.
I do not believe that quality costs more than it returns; on the contrary, a quality approach will always deliver solid results. With a quality approach, the biggest savings are realised on the post-release issues; that is to say having the least issues post-release means that the project is most likely to come in on budget. All too often the overrun bleeds into the support budget without question.
Of course, a caveat here is how post-release issues are tracked. If they are tracked under some separate catch-all "support" [or indeed "other"] budget, then you could fool yourself into thinking you are more successful than you are, as an organisation. For me, all project issues should be accounted to the project and the budget closed only once the client has formally signed off the project as delivered, and the project formally moves into support. Only if the project is accurately tracked will the financials accurately model the real world, thus permitting informed reflection.
No hard and fast rules
Each quality measure should be applied pragmatically, rather than assuming it is a one-size-fits-all solution. Specific examples are discussed following. These are not exhaustive, but are meant to inspire the reader to review their own approach to quality [or lack of] and to come up with quality measures that fit your organisation's unique needs.Design
Do not produce design documentation purely as a paper-generation exercise to satisfy a project deliverable. A design document is always useful and can be pitched at different levels for the intended audience. High-level wording, including industry buzz-words, for the client and their management are appropriate for a less-technical business audience. Low-level technical wording, with discussion of specific objects and their implementation [versus other approaches] are appropriate for atomic elements of the solution and the technical audience that will require the information as input. Do not feel the need to make the document wordy; the shorter the better. Pictorial information is always welcomed in such documents.Development
Most organisations have coding standards. Adhering to these alone will not generate quality software. They are more concerned with style and syntax than semantics. Implementing design patterns correctly, for the appropriate use, will improve the quality of your code base. Each pattern is looking to provide something different: increased testability, increased performance, increased security, increased resilience, increased interoperability, decreased coupling, and so on.One thing I am sure of is that code should be well-documented. Ask yourself, "could the most junior member of the team understand this code in my absence?" I always aim for comments for entry-level staff. That is not to say the code has been simplified at all, but it is laid out clearly and documented appropriately.
Pair programming or parallel programming?
In software, there exists the concept of pair programming. This is not something I have tried, and so I cannot pass any judgement. On the face of it, it seems counter-intuitive having two developers working on the same code at the same time, but this is purported to be negated by the improved output. One approach I have used however is parallel programming, or "two heads are better than one". Two developers are intentionally separated to work alone on the same piece of the solution, working to a prototype-level of functionality [i.e. the code works but lacks production-level error-handling, logging, UI, etc]. Once they have both got their prototypes working, the approaches are reviewed [by the same or other developer(s)] and the best of each is taken as the way forward. You will be looking to trade-off certain aspects against one-another: performance, robustness, clarity, maintainability, extensibility, etc. This approach should be used for the critical elements of the system, but as the quality increases as a result, can be used wider without fear of wasting time. Of course, a dependency of this approach is that the developers need to be on-board, and certainly should not have ego issues; it requires people to accept that they do not have the definitive "best" approach to any given situation and that collaborative working will always deliver the best results.Waterfall versus Agile methodologies
Nowadays Agile methodologies are commonplace. Some customers are sold an Agile approach, fully aware of the benefits and implications, others are sold a traditional fixed-price solution that is then implemented internally as an Agile project of fixed duration with the Project Manager representing the Customer.The benefits of an Agile approach is that it is iterative over short periods [say, two weeks] and so is responsive to change. Each iteration delivers production-quality functionality. Large projects benefit the most, as over time the needs of the business may change and the project may inspire the business to change the requirements as they see the possibilities unfold.
Waterfall by comparison is rigid and resistant to change; the cost of which can be very high for the paying customer. Organisations like fixed price solutions. If they buy a building, or a new printer or car, the cost is fixed. They desire the same predictable cost from their IT solutions.
When I am working fixed-price I tend to work in a hybrid manner. Rather than the top-down approach prescribed by waterfall, I pick a use case/business function and implement it fully end to end right through the application stack. This takes longest for the first but along the way you will have had to decide on your architectural approach as best suited to the business requirements. You should evaluate your options with prototype code, discuss the pros and cons with your peers, manager and customer to ensure all needs are best met. As you implement more and more business functionality you will write less and less code, all of which is of production quality. I find this approach delivers the solution the fastest, with quality in mind, and so if it is possible to deliver the solution within the fixed window, this will deliver it.
Test Driven Development or Tested Development?
I have worked on TDD projects. The TDD element thereof has been implemented with varying levels of understanding and success, as measured by the reduction in bugs [or lack of reduction!].TDD is a sound approach in my opinion, but not for the entire system.
Before TDD came along I always had a separate Test Project in my Visual Studio solution. By comparison to the very atomic testing TDD delivers, some of my tests were quite high-level, perhaps testing an entire business case in one go. This is clearly better than no testing at all, and if I encountered a bug, I would craft something more specific to test that bug and others "nearby".
Under TDD you write the test first, which will fail due to a lack of logic/implementation, and then you write/correct the code to pass the test. After a while [of writing good tests] you get into the habit of writing simpler code that performs more atomic tasks. Once this habit develops your code will be easier to understand and inherently more maintainable.
Now, left to my own free will, I tend to use a hybrid approach, developing the most critical and most used parts of the solution much closer to TDD, and then easing off and writing higher-level testing for the remainder of the system. The approach is a trade-off of time-used versus real quality achieved that I am happy with and delivers results.
Review failure and success
I am puzzled by organisations that only "review" a project, or sub-part thereof, when things go wrong, to whatever degree. Surely all projects of a non-repetitive nature should be reviewed, overall and more atomically, to agree what worked and what could have been improved. This should then lead into your "best practice" knowledge base, which may include document templates, documented procedures, coding design patterns, code examples, third-party utilities, all organised in such a way as to be found easily. All too often organisations reinvent the wheel without knowing it. Having a knowledge base intranet site with document libraries, images and wikis should be the norm, and the collaborative contribution and consumption of it by the whole team should be second nature.Hopefully there are some new ideas here to inspire you to improve the quality within your organisation!
