Category Archives: project management

Liability for Software in the Cloud

Leave a reply

Of the different theories under which a program could be sued (strict liability, negligence, criminal, intentional tort, fraud, negligent misrepresentation, malpractice, …), the most accurate and used are strict liability and negligence: the first applies to defective products, but negligence is more suitable for services. In the past decades, most software was characterized as a product: COTS and shrink-wrap products are clearly products, and even custom developed programs are products that may have support services under a different contract than that of the software license. These distinctions came from a time when traditional manufacturers were inflicting serious negative externalities on clients, but those of services were of little importance: much have been written about the need to impose strict liability without fault on software as a way to improve responsibility and quality, transferring the full cost of negative externalities to software companies. But this theory of liability has been rarely applied to software products, the truth being that the destructive potential of software is quite low except for medical devices, which are regulated by other provisions: strict liability covers unexpected and significant harm, and this is a rare event in software programs.

Forcing strict liability on programs will put many small software vendors out of business, and open-source will just disappear: as Alex Tabarrok notes, this is what happened in the aviation industry when manufacturers found that they could be sued for any aircraft ever produced. Only lifting these liabilities for old planes did revitalize the industry, with the unintended consequence that the end of manufacturers’ liability was associated with a significant reduction in the probability of an accident, opposite to what the former regulations intended. Moral hazard was small but pervasive, even in the face of death.

But SaaS and cloud computing are changing the software landscape: these really are services, so the negligence standard clearly applies. For sure, it’s the standard that best balances the interest of the parties: the cloud is full of SLAs, indeed. And even if these guarantees are not strong as the standard of strict liability, I wonder how much moral hazard will be introduced due to their proliferation: nowadays, the excuse that cloud providers are the root cause of system failure is getting more and more common.

Books on Project Management

Leave a reply
  • [amazon_link id=“0596007868” target=“_blank” ]The Art of Project Management[/amazon_link].  Wise insights are exceptionally uncommon. Practical guidance is plentiful, but all equally inconsequential. And wise and practical musings, rarer still: except within this book, a unique gem in a category of books that shines by its mediocrity. Well-thought and balanced in its theme choice, it covers every topic necessary to thrive in the always difficult to define role of project manager within a big software enterprise: for a better reading, a good exercise is to tweak every moral lesson offered in each section to the different contexts, scales and perspectives that could arise in other settings.
  • [amazon_link id=“0470560452” target=“_blank” ]One Strategy: Strategy, Planning and Decision Making[/amazon_link]. Project management is only side of the coin. Since software is by definition so malleable, projects can get as complex as desired, with no end in sight. Their success depends on the proper alignment of multiple tasks and roles: product design and planning, development, testing and usability, among others. All these must integrate into a single common vision, with no holes nor voids for coherence to emerge; quoting Heraclitus: “The unlike is joined together, and from differences results the most beautiful harmony”. This book recounts the strategy and roadmap of Windows 7, a titanic effort with little or none equivalent in the software industry: as technical as a success case can get, this book is a must to understand the current Microsoft organization.

Empirical, Evidence-Based Software Engineering

Leave a reply

These slides review the state of the art of Empirical, Evidence-based Software Engineering, a recent field of research whose goal is to get rid of fashionable practices, methodologies and clichés that are so sadly common in software development: more than a hundred papers are examined on a range of diverse topics such as complexity metrics, estimation, debugging, refactoring, agile methodologies, team organization, technical debt and software architecturing.

Software Development based on Financial Ratios

Leave a reply

Why did software component reuse never take root? Why is outsourcing within the software industry such a bad practice, even if other industries outsource all of their developments? Why do big software companies perform so bad and have such a poor innovation record?

From a purely financial viewpoint, focused on profitability ratios, these and other questions are far beyond all comprehension. But paradoxically, they emerge as the result of the blind application of financial theory to the software industry:

  • Reusing software would look like the shortest path to profitability: selling properly tested and documented software components over and over again was the holy grail of the software industry decades ago; in fact, that’s how all the manufacturing industry works. But the incorporation of other costs (friction, learning, integration, …) discourages this model of development; and what really abolished this trend  was the rejection of whole software stacks based on the elusive nature of some requirements that were not taken into account because componentized software is not built by iterating on customer feedback since its very beginning.
  • Outsourcing is the preferred way to develop software in every industry, except for the software industry itself: financially speaking, outsourcing improves every efficiency measure, lowers fixed costs and improves flexibility. What’s not to like? That what is difficult to measure: the cost of lost knowledge and the opportunity cost of not being able to innovate based on this knowledge; and finally, the cost of not surviving because competition was more learned and readier.
  • Big companies do not innovate because all their projects start to get measured by IRR (Internal Rate of Return): but this ratio prioritizes short term, low-value projects over long-term projects. Start-ups teach us that it takes 7–10 years to full profitability and investment amortization: no wonder big companies fail to innovate.

And there are many more examples: striving for a better ROCE (Return on Capital Employed) on software projects is not a very good idea, since capital is not a scarce resource, qualified labour is; so economizing on an abundant asset is absolutely wrong. And that for any other return-like ratio: they will strip off any software company and deprive it of its most precious assets.

On Decentralized Decision Making

Leave a reply

The highest proof of virtue is to possess boundless power without abusing it

Lord Macaulay

Software projects, unlike most projects, are highly variable: full of non-repetitive tasks with high variability and uncertainty. To control their outcome, there’s a counterproductive tendency to micromanage every little aspect of them, when everyone agrees that giving individual responsibility over the WBS it’s a much better approach. Following, my recipe to decentralize their management:

    1. Convert conventional unitary metrics (profits, time, revenue & unit cost) to a standard multi-dimensional metric (vg. profits over the life cycle)
    2. Based on the previous metric, model performance metrics (vg. cost overrun, quality shortfalls, delays, risk change)
    3. Conduct a sensitivity analysis of forgoing any of the performance metrics
    4. From the previous analysis, derive practical results based on the total profit impact of missing a performance metric (vg. impact of 1% quality shortfall is 10 times 1% loss of cost overrun)
    5. Based on the previous insights, generate and disseminate decision rules to be applied locally by every team member. Thus, the resulting decision rules are decentralizing decision making, enabling their application to every little aspect of the project while achieving the same global optimum that the centralization of decision making attains.

Note that the underlying idea is anything but new: principles-based regulation follows the same spirit to solve analogous problems.

After all, it’s human nature: the desire to concentrate power, to rule and demand obedience beyond right and reason. Wisdom and virtue are their only counterbalances: because only the righteous consider power as the wisdom of when not to use any of their received power at all.