The Fatware Matrix

The human desire for choice is unlimited. At least this is advocated in many psychological theories of human motivation and economic theories of rational choice. And this is so natural – after all having multiple options gives us the freedom to select the ones which suit us best. However scientists have recently found just the opposite – having “too many” choice might be demotivating and even repellent to consumers. The most popular demonstration of this is the so called Jam experiment. It was conducted at a grocery store with two different tasting booths – one offering a limited number of flavors of jam (just 6) and one with quite an extensive collection (of 24). What researchers found was striking. Although the variety in the extensive-choice condition was initially more attractive, the percentage of consumers who subsequently purchased jars of jam was much lower than in the limited-choice condition – 3% vs. 30%!
The features of a particular software system could be defined as the options available to its consumers (whether functional or non-functional). Following the same fundamental assumption that rich set of choices is desirable – а tendency emerged to steadily and persistently increase the number of features. As this expansion never stops, software systems often become vulnerable to feature creep (or creeping featurism, featuritis, bloatware, etc.). And feature creep is proved to be a major contributor for most of the cost and schedules overruns, and is one of the root causes for software overengineering, software bloat and technical debt. Now taking into consideration recent scientific findings that ‘too many” options actually reduce consumers’ motivation to buy (the argument towards feature-rich software systems) – it is quite intriguing why is this trend still so strong today?
The Fatware Matrix is a tool to visualize the fat in a software system – all the features which do not bring any value to consumers but are costly to change and maintain. As such it could be used to manage and continuously improve the levels of feature creep and technical dept.

Continue reading →

What’s valued most by Global Software Leaders?

The presented industrial report examines the espoused organizational values of some of the most successful software organizations (according to PricewaterhouseCoopers’s Global Software Leaders). Its main purpose is to provide useful insights which could be used by other companies (1) for benchmarking and identifying possible improvements in business performance; and (2) strengthening organization’s positioning and/or gaining competitive advantages (by focusing on values which are often overlooked by the software industry).

Continue reading →

What’s valued most by the Bulgarian Software and ICT industry?

The presented industrial report examines the espoused organizational values of some of the leading organizations in the Bulgarian software and ICT industry. Its main purpose is to provide useful insights which could be used: (1) for benchmarking and identifying possible improvements in business performance; and (2) strengthening organization’s positioning and/or gaining additional competitive advantages (by focusing on values which are overlooked by others).

Continue reading →

The Zmey Planning

Zmey is a popular dragon form the Slavic mythology with three heads, wings and a snake’s body. It personifies evil and often demands tribute from villages or small towns in the form of gold. In an attempt to defeat the Zmey and relieve the people from this odious creature many legendary heroes have lost their lives. So have software engineers. But in their case the Zmey ruins software estimates and brings chaos to software schedules.
There might be many reasons why software estimates are so inaccurate. The presented estimation and planning technique focuses on three major ones. The first is complexity. It is defined by: (1) the difficulty of the problem to be solved (e.g. data complexity, decisional / branching complexity, etc.); (2) the impact on existing functionality; (3) the presence of non-functional requirements (aka. quality attributes); and (4) the existing level of technical debt (incl. feature creep and code bloat). The second one is related to uncertainty. It is measured by: (1) the need of knowledge creation (or gaining new skills and qualifications); (2) the uniqueness / variability / diversity of the requested change (or the need for creativity and innovation); (3) the presence of business, management or other type of social pressure; (4) the expected level of dynamicity (e.g. tasks switching / interruptions / hands-off, intensity of expected communication, etc.); (5) the presence of dependencies (e.g. 3-rd party integrations, distributed environments / teams, etc.); and (6) anticipated obstacles and impediments (e.g. problems with the used software engineering tools, working environments, etc.). The last concern is the vagueness of the requirements. It represents quality characteristics as: (1) correctness (or targeting a real business need); (2) completeness (or covering all aspects of the requested change – preferably documented into one place); (3) clarity (or specifying what is needed in an unambiguous and not confusing way); (4) consistency (or being aligned with already existing functionality and/or other requirements); and (5) testability (or specifying concrete acceptance criteria).
Complexity, uncertainty and vagueness are actually the three heads of the Zmey. They often tyrannize software engineers and make their estimating and scheduling efforts doomed to fail. The presented estimation and planning technique could be used to determine the tribute demanded by the Zmey (aka the zmey tax) and identify possible actions for minimizing its detrimental impact on software estimation and scheduling. But remember – you could never relieve yourself from the Zmey. Even if you chop off his heads they would quickly re-grow for your next estimation and scheduling endeavor.

Continue reading →