It seems that the sales & marketing folks have CRM dashboards to help with visibility and predictability. But do the software delivery and engineering folks to enable them with visibility and predictability?

Now they have zAgile. http://www.zagile.com

- Herdiansyah Nurhidayat -
http://hdsconsultant.blogspot.com/

Today, the difference is we are using more SaaS products and the bugs are in the UI. The difference is a more a more experienced user. Today, we don’t do Q/A with designed in and feature based processes, we use test; after the fact.

Nice article! I do have one suggestion though. I have one more question they might want to add:

Question Five: How many customers does this bug impact? (Customer Impact)

It matters because you might have a severe bug (Question One, Severity is high) that only impacts a handful of customers out of tens of thousands. For example, you might have a crash bug that only happens with a specific hardware configuration that few if any customers use. A bug with less severity but higher customer impact should be given priority in my opinion.

What is the cost of being in the market with buggy software vs. being late with bulletproof software? What is the cost of not building new features because you are bug fixing?

Poor quality isn’t seen as easy as a cost or time over run.

Quality control and testing phases during the SDLC are also key to producing code with minimal bugs/defects. Applying Six Sigma practises to software development is a new strategy to leverage these methodologies that originated in the manufacturing industry (Motorola and Toyota). The intention is to reduce defects (bugs) in your product to a minimum. Considering that during the project lifecycle, the testing phase is typically at the end, time constraints and budgets sometimes force the business to sacrifice this critical phase to cut costs and/or meet deadlines.

http://www.isixsigma.com/library/content/c020603a.asp
“Six Sigma emphasizes quality from the beginning. Most often conventional Software Development Life Cycle (SDLC) methodologies introduce the quality processes towards the end of the project cycle, just before implementation.”

Another factor worth acknowledging is now of increasing significance in the age of ‘software as a service’ and new distribution/revenue models. When offerings exist in continuous trial mode, often ‘for free’ at point of use but tied to advertising revenue streams, where they are continuously updated and have no guarantee of backward compatibility (hello Google). As mentioned earlier these are much faster to release and gain market share when the testing is largely outsourced to the user.

Clearly this serves a market hungry for innovation and commoditised offerings, but also suggests that many users will bear with relatively unstable applications, limited customisation and lower perceived quality. And the market gets what the market wants.

This trend may decimate the ‘mid-market’ and smaller software vendors (ISVs), but perversely may also drive premium users (often in the enterprise or government) towards the arms of the larger suppliers (irrespective of whether on a licensing model or ‘free’ open source plus premium support). As ever a large installed base acts as a drag against rapid product innovation, but also a check against lowering the quality of functionality or support.

Nowadays most companies altered the testing part in such a way that actual alpha testing is called beta and actual beta version is nothing but the .0 release. So those poor souls who purchase .0 versions end up doing beta testing for the product companies, of course at their own cost.

Secondly, the architectural principles are not implemented religiously. An exceptional principal engineer in most circumstances is wildly promoted as an architect, evangelist etc fancy names. This has infact diluted the importance of architectural accomplishments and thus leading to increased workforce, always changing ARCHITECTURE which in turn increases budgets and schedules and puts pressure on the project teams. It is under this pressure that the teams start under-performing engineering tasks. The Result is increased QC cycles and deviation from deadlines. An increased pressure to release a WORKABLE product and not a BUG FREE product.

Issues:

1. Business factor – Customers want cheap software pushing vendors to reduce their cost. Vendor push developers to deliver low quality ‘quick-hack’ written software. Later plan is to make clients sign maintenance contract for maintenance/bug fixes.

2. Management – Wrong hiring, getting someone without relevant software development experience on top to manage a software project is a big mistake. Developers who are unhappy will leave and the code will passed over to many different people evolving into spaghetti code that is not maintainable and buggy. Project managers without experience in software development will often “imagine and talk” about their dream ideas/concepts and push the developers to deliver. Almost everyone can produce reasonable good ideas, but remember that an idea worth nothing. Execution does matter!

3. Engineering approach – Incorrect mindset of some managers, developers or technical architects who do not think long term. A software that is forced to deliver quickly and not properly done will always cost more to fix/maintain later. This is the most problem that many managers, architects and developers don’t realize.

At the same time employers are looking for cheapest (rather than best) talent. Most of software engineering processes are “evil” – i.e. cause even good people to produce bad work. For example, people are rewarded for individual achievement when it takes coordinated work of a team to build a “knowledge product” like software.

Buggy products are released because customers accept buggy software – being the first to market beats being bug-free hands down. Big part of that is currently standard ULA – the purchaser/user of software releases the maker from any responsibility for any problems caused by the software.

1. The quality of “cheaper commodity” is much worse in many cases
2. Employees do not have any bonds with their employers either and are ready to leave at first convenience. They are not interested to deliver high quality product. QA is not able to find all potential problems (e.g. scalability issues, race conditions, memory leaks, etc.). In other words, software engineers have a “contractor mentality” nowadays that hurts the quality of software big time.

All other issues that have been discussed in this thread have been valid in the past as well. The trend that I’ve described is relatively new.

It’s that simple.

Causes for a defects are project duration, skills and talents of resources at various department, Cost/price of the project/product etc. But all these defects are human dependent. By making entire project system dependent (following process, automated testing etc.), to some extent defects can be reduced, but not 100%.

Inspite of following process, programming methodologies, best practices, I would like to highlight one of the best practice (incase of product development), i.e. code re-factoring at regular intervals. Every design has lifecycle, the design / architecture has to be modified or tweaked at regular intervals. Again code re-factoring at various levels from high level design to low design, when ever and where ever required.

Also I would like to high light one more factor, Quality = Time = Price. When ever there is a cut down in time or cost beyond limit, there will be some amout of quality degradation. The reason for the reduction, is either client want final delivery with so and so date and/or vendor want to save cost also or deliver withing agreed date (as there is huge amount of compitition). So any reduction in the time or price beyond range with fewer / less skilled resource has an impact on the final quality.

Several reasons:

1. Business factor – Customer often wants to keep their cost low squeezing the vendor while some vendors tried to accommodate it by rushing SDLC to keep their time/cost low thus neglecting the quality issues. Vendors just want to get the dirty job done with a ‘hit and run’ mindset and expects the client to sign a maintenance contract for bug fixes later.

2. Management problem – When a company hires people who does not have enough technical experience or software development knowledge on top, problems arise. Some project managers are hired simply because they can “talk” not because they are good. When it comes to managing a software project, will do things their own way outside proper engineering process and push the developers to get things done quick and dirty. Usually these people do not even understand why and how doing so will result the cost to fix or maintain it later is even higher. After all, they will still get appreciation from top management while developers are often blamed for buggy software. Moreover, when developers who are not satisfied with such people managing a software project, they will leave and the cycle repeats. A software project that is moved into too many different developers before it is mature will often result into spaghetti code that is not maintainable and buggy!

3. Bad engineering practice/mindset – There are some technical architects and developers who don’t even practice common unit testing at all and think very short term. I notice a lot of developers nowadays shifted their design effort mindset to 3:3:4 (design:code:debug) approach rather than 6:3:1 (design:code:debug) approach. This is bad especially if they just wanted to show they have done something to the management in early stage but in long run, such practice is not sustainable.

In short, business decision and getting the right people from top to bottom does make a big impact towards the software quality of a company.