Review Standish Group – CHAOS 2020: Beyond Infinity

Mike's Notes

I have been researching and reviewing the material referenced by Roger Sessions. This is about the Standish Group.

There is now a collection of Standish reference material in the library as part of the Roger Sessions collection.

Resources

References

  • Standish Group – CHAOS Report 2020

Repository

  • Home > Ajabbi Research > Library > Authors > Roger Sessions
  • Home > Handbook > 

Last Updated

01/06/2025

Review Standish Group – CHAOS 2020: Beyond Infinity

By: Henny Portman
Henny Portman's Blog: 06/01/2021

A few weeks ago, I received the latest report from the Standish Group – CHAOS 2020: Beyond Infinity – written by Jim Johnson. Every two years the Standish Group publish a new CHAOS Report.

These reports include classic CHAOS data in different forms with many charts. Most of the charts come from the CHAOS database of over 50,000 in-depth project profiles of the previous 5 years. You have probably seen some of those yellow-red-green charts showing e.g., challenged, failed and successful project percentages. 

The book contains ten sections and an epilogue:

Section I:

Factors of Success describes the three factors (good sponsor, good team and good place) the Standish Group has determined most seriously affect the outcome of a software project. Specific attention has been given how poor decision latency and emotional maturity level affect outcomes and the success ladder benchmark.

Section II:

Classic CHAOS provides the familiar charts and information generally found in CHAOS reports. E.g., resolution by traditional measurement, modern measurements, pure measurements and “Bull’s Eye” measurements.

Section III:

Type and styles of projects breaks down project resolution by measurement types and styles of delivery method.

In the next three sections we get an overview of the principles for the good sponsor, the good team and the good place. Each principle is explained in detail, including the required skills to improve the principle and a related chart showing the resolution of all software projects due to poorly skilled, moderately skilled, skilled and very skilled.

Section IV:

The Good Sponsor discusses the skills needed to be a good sponsor. The good sponsor is the soul of the project. The sponsor breathes life into a project, and without the sponsor there is no project. Improving the skills of the project sponsor is the number-one factor of success – and also the easiest to improve upon, since each project has only one. Principles for a good sponsor are: 

  • The Decision Latency principle
  • The Vision Principle
  • The Work Smart Principle
  • The Daydream Principle
  • The Influence Principle 
  • The Passionate Principle
  • The People Principle
  • The Tension Principle 
  • The Torque Principle
  • The Progress Principle.

Section V:

The Good Team discusses the skills involved in being a good team. The good team is the project’s workhorse. They do the heavy lifting. The sponsor breathes life into the project, but the team takes that breath and uses it to create a viable product that the organization can use and from which it derives value. Since we recommend small teams, this is the second easiest area to improve. Principles for a good team are: 

  • The Influential Principle
  • The Mindfulness Principle
  • The Five Deadly Sins Principle
  • The Problem-Solver Principle
  • The Communication Principle
  • The Acceptance Principle
  • The Respectfulness Principle
  • The Confrontationist Principle
  • The Civility Principle
  • The Driven Principle.

Section VI:

The Good Place covers what’s needed to provide a good place for projects to thrive. The good place is where the sponsor and team work to create the product. It’s made up of the people who support both sponsor and team. These people can be helpful or destructive. It’s imperative that the organization work to improve their skills if a project is to succeed. This area is the hardest to mitigate, since each project is touched by so many people. Principles for a good place are: 

  • The Decision Latency Principle
  • The Emotional Maturity Principle
  • The Communication Principle
  • The User Involvement Principle
  • The Five Deadly Sins Principle
  • The Negotiation Principle
  • The Competency Principle
  • The Optimization Principle
  • The Rapid Execution Principle
  • The Enterprise Architecture Principle.

Section VII:

Overview of the CHAOS Database explains the process of creating project cases and adjudicating them for inclusion in the CHAOS database.

Section VIII:

New Resolution Benchmark offers an overview of this new benchmark, which will replace the original in the CHAOS database. The Project Resolution Benchmark is a self-service instrument that uses a three-step method to help benchmark your organization against similar organizations on the basis of size, industry, project mix, types, and capability.

Section IX:

The Dutch Connection describes and celebrates the contributions made by our colleagues in the Netherlands and Belgium and their effect on our research.

Section X:

Myths and Illusions debunks some typical beliefs about “project improvement.” By using the data points from the database. The busted myths are:

  • Successful projects have a highly skilled project manager
  • Project management tools help project success
  • All projects must have clear business objectives
  • Incomplete requirements cause challenged and failed projects.

Epilogue

The Epilogue takes a look at 60 years of software development. The Standish Group has come up with four distinct evolutionary periods of developing software. The first period, which ran roughly from 1960 to 1980, is called “the Wild West”. The Waterfall Period ran from 1980 to about 2000. The Agile Period started around the year 2000 – and their prediction is that it will end shortly. They are now seeing the beginning of what they call the Infinite Flow Period, and they imagine that the Flow Period will last at least 20 years. In the Flow Period, there will be no project budgets, project plans, project managers, or Scrum masters. There will be a budget for the pipeline, which is a pure direct cost of the output. There will also be a cost to manage the pipeline, which will reduce the current project overhead cost by as much as 90%. This will be accomplished by reducing and eliminating most of the current project management activities. Functional description of work will come into the pipeline and out of the pipeline fully usable. Change will happen continuously, but in small increments that will keep everything current, useful, and more acceptable to users, rather than startling them with a “big bang boom” result (in a next blog I will dive into some details of the Flow method).

Conclusion:

CHAOS stands for the Comprehensive Human Appraisal for Originating Software. It’s all about the human factor. If you are looking for areas of improvement of your organizational project management skills (good sponsor, good team and good place), this guide gives a great overview where you could get the highest benefits from your investments. It gives excellent insights in root causes for project failure or success.

A pity this is the last CHAOS report (there will be an updated version in 2021, but that will not be a completely new CHAOS report). Given that The Standish Group are recommending you move to Flow, they state that there is no need for them to continue to research software projects. I would say not all projects are software projects, why not collect datapoints from non-software projects and start building a database and analyze the impact of the good sponsor, the good team and the good place for these projects too.

To order CHAOS 2020: Beyond Infinity

By , No comments:
Tags , , , ,

Ten Laws That Govern Enterprise Architecture

Mike's Notes

Another excellent article by Roger Sessions.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Authors > Roger Sessions
  • Home > Handbook > 

Last Updated

01/06/2025

Ten Laws That Govern Enterprise Architecture

By: Roger Session
LinkedIn: 24/06/2016

Lead Architect of the IT Simplification Initiative (ITSI), leveraging mathematics to build simpler IT.

Every engineering discipline is governed by specific mathematical laws. Bridge designers must understand the laws of Tension and Compression. Any bridge designed in violation of these laws will collapse. Rocket ship designers must understand Newton’s Laws of Motion. Any rocket ship designed in violation of Newton’s laws will destruct. Aqueduct designers must understand the Laws of Hydraulics. Any aqueduct designed in violation of these laws will block.

How many people would knowingly drive on bridges that violate the laws of Tension and Compression? How many would ride a rocket ship that ignores Newton’s Laws of Motion? How many would hook up their toilet to aqueducts designed by people who poo-poo the laws of Hydraulics?

Like these engineering disciplines, enterprise architecture is governed by specific mathematical laws. However in marked contrast to these other disciplines, few enterprise architects understand the laws that govern their field. Even fewer executives demand that the high cost designs they are funding take into account the most fundamental laws that will determine their success.

This article is a Call to Action. It is a call to enterprise architects to start designing systems that conform to those laws rather than flaunting them. It is a call to executives to start demanding that all designs be subject to a proof of conformity to these laws. To design a large IT system that violates the Laws of Complexity is every bit as negligent as designing a bridge that violates the Laws of Tension and Compression.

As a starting point for this critical discussion, here are what I believe are the ten most important Laws of Complexity:

  1. Complexity = Functional Complexity + Dependency Complexity
  2. Viability = c /Complexity
  3. Value = Useful Functionality / Complexity
  4. Complexity increases exponentially
  5. Capacity to Manage Complexity increases linearly
  6. When partitioning independent elements, partition complexity is driven by subset size.
  7. When partitioning dependent elements, partition complexity is driven by element assignment.
  8. |Non-Optimal Partitions (NOPs)| >> |Optimal Partitions (OPs)|
  9. Complexity (NOPs) >> Complexity (OPs)
  10. OPs can only be found with directed methodologies.

I will write about these laws in more detail in upcoming articles. Stay tuned!

By , No comments:

How to Learn the Math Needed for Machine Learning

Mike's Notes

An outline of what I need to study.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Towards Data Science
  • Home > Handbook > 

Last Updated

31/05/2025

How to Learn the Math Needed for Machine Learning

By: Edgor Howell
Towards Data Science: 15/05/2025

A breakdown of the three fundamental math fields required for machine learning: statistics, linear algebra, and calculus.

Maths can be a scary topic for people.

Many of you want to work in machine learning, but the maths skills needed may seem overwhelming.

I am here to tell you that it’s nowhere as intimidating as you may think and to give you a roadmap, resources, and advice on how to learn math effectively.

Let’s get into it!

Do you need maths for machine learning?

I often get asked:

Do you need to know maths to work in machine learning?

The short answer is generally yes, but the depth and extent of maths you need to know depends on the type of role you are going for.

A research-based role like:

  • Research Engineer — Engineer who runs experiments based on research ideas.
  • Research Scientist — A full-time researcher on cutting edge models.
  • Applied Research Scientist — Somewhere between research and industry.

You will particularly need strong maths skills.

It also depends on what company you work for. If you are a machine learning engineer or data scientist or any tech role at:

  • Deepmind
  • Microsoft AI
  • Meta Research
  • Google Research

You will also need strong maths skills because you are working in a research lab, akin to a university or college research lab.

In fact, most machine learning and AI research is done at large corporations rather than universities due to the financial costs of running models on massive data, which can be millions of pounds.

For these roles and positions I have mentioned, your maths skills will need to be a minimum of a bachelor’s degree in a subject such as math, physics, computer science, statistics, or engineering.

However, ideally, you will have a master’s or PhD in one of those subjects, as these degrees teach the research skills needed for these research-based roles or companies.

This may sound heartening to some of you, but this is just the truth from the statistics.

According to a notebook from the 2021 Kaggle Machine Learning & Data Science Survey, the research scientist role is highly popular among PhD and doctorates.

...

And in general, the higher your education the more money you will earn, which will correlate with maths knowledge.

...

However, if you want to work in the industry on production projects, the math skills needed are considerably less. Many people I know working as machine learning engineers and data scientists don’t have a “target” background.

This is because industry is not so “research” intensive. It’s often about determining the optimal business strategy or decision and then implementing that into a machine-learning model.

Sometimes, a simple decision engine is only required, and machine learning would be overkill.

High school maths knowledge is usually sufficient for these roles. Still, you may need to brush up on key areas, particularly for interviews or specific specialisms like reinforcement learning or time series, which are quite maths-intensive.

To be honest, the majority of roles are in industry, so the maths skills needed for most people will not be at the PhD or master’s level. 

But I would be lying if I said these qualifications do not give you an advantage.

What maths do you need to know?

There are three core areas you need to know:

  • Statistics
  • Calculus
  • Linear Algebra

Statistics

I may be slightly biased, but statistics is the most important area you should know and put the most effort into understanding.

Most machine learning originated from statistical learning theory, so learning statistics will mean you will inherently learn machine learning or its basics.

These are the areas you should study:

  • Descriptive Statistics — This is useful for general analysis and diagnosing your models. This is all about summarising and portraying your data in the best way.
    • Averages: Mean, Median, Mode
    • Spread: Standard Deviation, Variance, Covariance
    • Plots: Bar, Line, Pie, Histograms, Error Bars
  • Probability Distributions — This is the heart of statistics as it defines the shape of the probability of events. There are many, and I mean many, distributions, but you certainly don’t need to learn all of them.

    • Normal
    • Binomial
    • Gamma
    • Log-normal
    • Poisson
    • Geometric
  • Probability Theory — As I said earlier, machine learning is based on statistical learning, which comes from understanding how probability works. The most important concepts are

    • Maximum likelihood estimation
    • Central limit theorem
    • Bayesian statistics
  • Hypothesis Testing —Most real-world use cases of data and machine learning revolve around testing. You will test your models in production or carry out an A/B test for your customers; therefore, understanding how to run hypothesis tests is very important.

    • Significance Level
    • Z-Test
    • T-Test
    • Chi-Square Test
    • Sampling
  • Modelling & Inference —Models like linear regression, logistic regression, polynomial regression, and any regression algorithm originally came from statistics, not machine learning.

    • Linear Regression
    • Logistic Regression
    • Polynomial Regression
    • Model Residuals
    • Model Uncertainty
    • Generalised Linear Models

Calculus

Most machine learning algorithms learn from gradient descent in one way or another. And, gradient descent has its roots in calculus.

There are two main areas in calculus you should cover:

  • Differentiation
    • What is a derivative?
    • Derivatives of common functions.
    • Turning point, maxima, minima and saddle points.
    • Partial derivatives and multivariable calculus.
    • Chain and product rules.
    • Convex vs non-convex differentiable functions.
  • Integration

    • What is integration?
    • Integration by parts and substitution.
    • The integral of common functions.
    • Integration of areas and volumes.

Linear Algebra

Linear algebra is used everywhere in machine learning, and a lot in deep learning. Most models represent data and features as matrices and vectors.

  • Vectors 
    • What are vectors
    • Magnitude, direction
    • Dot product
    • Vector product
    • Vector operations (addition, subtraction, etc)
  • Matrices 
    • What is a matrix
    • Trace
    • Inverse
    • Transpose
    • Determinants
    • Dot product
    • Matrix decomposition
  • Eigenvalues & Eigenvectors 
    • Finding eigenvectors
    • Eigenvalue decomposition
    • Spectrum analysis

Best Resources

There are loads of resources, and it really comes down to your learning style.

If you are after textbooks, then you can’t go wrong with the following and is pretty much all you need:

  • Practical Statistics For Data Scientist — I recommend this book all the time and for good reason. This is the only textbook you realistically need to learn the statistics for Data Science and machine learning.
  • Mathematics for Machine Learning — As the name implies, this textbook will teach the maths for machine learning. A lot of the information in this book may be overkill, but your maths skills will be excellent if you study everything.

If you want some online courses, I have heard good things about the following ones.

  • Mathematics for Machine Learning and Data Science Specialisation — This course is by DeepLearning.AI, the same people who made the Machine Learning Specialisation, arguably the best machine learning course.

Learning Advice

The amount of maths content you need to learn may seem overwhelming, but don’t worry.

The main thing is to break it down step by step.

Pick one of the three: statistics, Linear Algebra or calculus.

Look at the things I wrote above you need to know and choose one resource. It doesn’t have to be any of the ones I recommended above.

That’s the initial work done. Don’t overcomplicate by looking for the “best resource” because such a thing doesn’t exist.

Now, start working through the resources, but don’t just blindly read or watch the videos.

Actively take notes and document your understanding. I personally write blog posts, which essentially employ the Feynman technique, as I am, in a way, “teaching” others what I know.

Writing blogs may be too much for some people, so just make sure you have good notes, either physically or digitally, that are in your own words and that you can reference later.

The learning process is generally quite simple, and there have been studies done on how to do it effectively. The general gist is:

  • Do a little bit every day
  • Review old concepts frequently (spaced repetition)
  • Document your learning
  • It’s all about the process; follow it, and you will learn!

By , No comments:
Tags , , , ,

How to be a great thinker

Mike's Notes

This says it all.

Resources

References

  • Vienna: How the City of Ideas Created the Modern World by Dr Richard Crockett

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

30/05/2025

How to be a great thinker

By: Simon Kuper
FT: 22/05/2025

Simon Kuper is a British, and naturalized French, author and journalist, best known for his work at the Financial Times and as a football writer.

Born in Uganda to South African parents, Kuper spent most of his childhood in the Netherlands and lives in Paris. After studies at Oxford, Harvard University and the Technische Universität Berlin, Kuper started his career in journalism at the FT in 1994, where he today writes about a wide range of topics, such as politics, society, culture, sports and urban planning. - Wikipedia

Most people are getting dumber. Largely because of the smartphone, we’re in an era of declining attention spans, reading skills, numeracy and verbal reasoning. How to buck the trend? I’ve charted seven intellectual habits of the best thinkers. True, these people exist in a different league from the rest of us. To use an analogy from computing, their high processing power allows them to crunch vast amounts of data from multiple domains. In other words, they have intellectual overcapacity. Still, we can learn from their methods. These can sound obvious, but few people live by them.

Read books.

A book is still the best technology to convey the nuanced complexity of the world. That complexity is a check on pure ideology. People who want to simplify the world will prefer online conspiracy theories. 

Don’t use screens much.

That frees time for books and creates more interstitial moments when the mind is left unoccupied, has freedom to roam and makes new connections. Darwin, Nietzsche and Kant experienced these moments on walks. The biochemist Jennifer Doudna says she gets insights when “out weeding my tomato plants” or while asleep.  

Do your own work, not the world’s.

The best thinkers don’t waste much time maximising their income or climbing hierarchies. Doudna left Berkeley to lead discovery research at biotech company Genentech. She lasted two months there. Needing full scientific freedom, she returned to Berkeley, where she ended up winning the chemistry Nobel Prize for co-inventing the gene-editing tool Crispr.

Be multidisciplinary.

Prewar Vienna produced thinkers including Freud, Hayek, Kurt Gödel and the irreducible polymath John von Neumann. The structure of the city’s university helped. Most subjects were taught within the faculties of either law or philosophy. That blurred boundaries between disciplines, writes Richard Cockett in Vienna: How the City of Ideas Created the Modern World. “There were no arbitrary divisions between ‘science’ and ‘humanities’ — all was ‘philosophy’, in its purest sense, the study of fundamental questions.” 

Hayek, for instance, “trained at home as a botanist to a quasi-professional level; he then graduated in law, received a doctorate in political science from the university, but . . . spent most of his time there studying psychology, all before becoming a revered economist.”

Breaking through silos goes against the set-up of modern academia. It also requires unprecedented processing power, given how much knowledge has accumulated in each field. But insights from one discipline can still revolutionise another. The psychologist Daniel Kahneman won the Nobel Prize for economics for his findings on human irrationality. 

Be an empiricist who values ideas.

During the second world war, Isaiah Berlin was first secretary at the British embassy in Washington. His weekly reports on the American political situation were brilliant empirical accounts of the world as it was. They mesmerised Winston Churchill, who was desperate to meet Berlin. (Due to a mix-up, Churchill invited Irving Berlin for lunch instead. The composer was baffled to be asked by Churchill himself, “When do you think the European war will end?”)

In March 1944, Isaiah Berlin returned from Washington to London on a bomber plane. He had to wear an oxygen mask all flight, wasn’t allowed to sleep for fear he would suffocate, and couldn’t read as there was no light. “One was therefore reduced to a most terrible thing,” he recalled, “to having to think — and I had to think for about seven or eight hours in this bomber.” During this long interstitial moment, Berlin decided to become an historian of ideas. He ended up writing the classic essays The Hedgehog and the Fox and Two Concepts of Liberty. 

Always assume you might be wrong.

Mediocre thinkers prefer to confirm their initial assumptions. This “confirmation bias” stops them reaching new or deeper insights. By contrast, Darwin was always composing arguments against his own theories. 

Keep learning from everyone.

Only mediocrities boast as adults about where they went to university aged 18. They imagine that intelligence is innate and static. In fact, people become more or less intelligent through life, depending on how hard they think. The best thinkers are always learning from others, no matter how young or low-status. I remember being at a dinner table where the two people who talked least and listened hardest were the two Nobel laureates.

By , 1 comment:
Tags ,

Measuring IT Complexity

Mike's Notes

Here is a small extract of an excellent paper written by Roger Sessions in 2009. It describes the maths he uses to describe IT complexity.

Sadly, his websites have not been updated for years, and many of the links to his excellent papers are now broken.

Usually, I use a webcrawler to archive excellent websites, but I didn't add ObjectWatch. I am now actively scouring the web to create an electronic archive of his work before it disappears.

His work was brilliant and deserves a wider audience.

Resources

References

  • The IT Complexity Crisis: Danger and Opportunity. A White Paper by Roger Sessions. October 22, 2009
  • Fact and Fallacies About Software Engineering. By Robert Glass
  • Woodfield, Scott N. 1979. “An Experiment on Unit Increase in Problem Complexity.” IEEE Transactions on Software Engineering, (Mar.) p76-79 Scott N. Woodfield:

Repository

  • Home > Ajabbi Research > Library > Authors > Roger Sessions
  • Home > Handbook > 

Last Updated

30/05/2025

Measuring IT Complexity

By: Roger Sessions
ObjectWatch 22/10/2009

Roger Sessions, a tireless advocate for efficiency through simplicity, is the CTO of ObjectWatch, a company he founded thirteen years ago. He has written seven books including his most recent, Simple Architectures for Complex Enterprises, and dozens of articles. He assists both public and private sector organizations in reducing IT complexity by blending existing architectural methodologies and SIP. In addition, Sessions provides architectural reviews and analysis. Sessions holds multiple patents in software and architectural methodology. He is a Fellow of the International Association of Software Architects (IASA), Editor-in-Chief of the IASA Perspectives Journal, and a Microsoft recognized MVP in Enterprise Architecture. A frequent keynote speaker, Sessions has presented in countries around the world on the topics of IT Complexity and Enterprise Architecture. Sessions has a Masters Degree in Computer Science from the University of Pennsylvania. He lives in Chappell Hill, Texas.

Roger loves feedback (and a good, stirring debate or two!) Join Roger in his crusade against complexity. His blog is SimpleArchitectures.blogspot.com and his Twitter ID is @RSessions.

...

Measuring IT complexity is easier than you might think. It all starts with Glass’s Law [06], that for every 25% increase in the complexity of the problem space, there is a 100% increase in the complexity of the solution space. In IT systems, there are two contributors to the complexity of the problem space. The first is the number of business functions in the system. The second is the number of connections that system has to other systems.

We need to start with a standard complexity unit (SCU). I’ll define one SCU as the amount of complexity that a system has which contains only one business function and no connections to other systems. Based on Glass’s Law, this is the least complex system possible.

Okay, we start with a system with one business function and no connections. By definition, this has 1 SCU. Now let’s start adding more business functions into the system. As we add more functions into the system, the number of SCUs goes up a predictable amount. This amount is calculated using Bird’s Formula. Bird is Chris Bird, who showed me how to rewrite Glass’s Law as a mathematical formula.

Let’s say a system S has bf number of business functions, and no connections to other systems. Then the number of SCUs in that system is given by

S = 10 raised to the power of ((log(2)/log(1.25) X log (bf))

The log(2) and the log(1.25) are both constants, and can thus be combined, giving

S = 10 raised to the power of (3.1 X log(bf))

or, more simply,

S = 10 3.1 log(bf)

Similarly, we can calculate the complexity of a system with one business function and cn connections to other systems. Note that I am simplifying the analysis by assuming that a new connection adds about the same amount of complexity as a new business function, which follows my experience. If you don’t agree, it is easy enough to modify the equation accordingly. But given my assumption, the complexity because of connections is as follows:

S = 10 3.1 log(cn)

Most systems have both multiple business functions and multiple connections, so we need to add the two together:

S = 10 3.1 log(bf) + 10 3.1 log(cn)

Most systems are not made of a single system, but a number of smaller systems, each of which has a complexity described by the above equations. An SOA, for example, would have multiple services, each of which has a complexity rating.

If we assume that our system is an SOA, then the complexity of the SOA as a whole is the summation of the complexity of each of the individual services. This is expressed as what I describe as Sessions’s Summation of Bird’s Formulation of Glass’s Law. It looks like this:


Now while Sessions’s Summation looks rather ugly, it is in fact easily calculated using a straightforward spreadsheet.

Sessions’s Summation gives us an easy way to compare two different architectures with respect to their complexity. Just plug both into Sessions’s Summation and read the resulting number. That number is the complexity in SCUs of the architecture. If one architecture has a total SCU of 1,000 and another a total SCU of 500, then the first is twice as complex as the second. It is also twice as likely to fail.

Notice that while functionality is a factor in complexity, it is not the major factor. Much larger factors are how many services there are, how many functions there are in each of the services and how those services are connected to each other.

...

[06] Glass’s Law comes from Robert Glass’s Fact and Fallacies About Software Engineering. He did not discover the law. He actually described it from a paper by Scott Woodfield, but Glass did more than anybody to publicize the law.

By , No comments:
Tags , , ,

Markus Covert: How to build a computer model of a cell

Mike's Notes

Another video interview with Marcus Covert. Pipi 6 was built by fusing Pipi with Covert's open-source cellular simulation software.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Authors > Markus Covert
  • Home > Handbook > 

Last Updated

05/06/2025

Markus Covert: How to build a computer model of a cell

By: Stanford Engineering Staff
The Future of Everything podcast: 20/10/2020

When Stanford bioengineer Markus Covert first decided to create a computer model able to simulate the behavior of a single cell, he was held back by more than an incomplete understanding of how a cell functions, but also by a lack of computer power.

His early models would take more than 10 hours to churn through a single simulation and that was when using a supercomputer capable of billions of calculations per second.

Nevertheless, in his quest toward what had been deemed “a grand challenge of the 21st century,” Covert pressed on and eventually published a paper announcing his success in building a model of just one microbe: E. coli, a popular subject in biological research. The model would allow researchers to run experiments not on living bacteria in a lab, but on a simulated cell on a computer.

After all was said and done, however, the greatest takeaway for Covert was that a cell is a very, very complex thing. There were fits and starts and at least one transcendent conceptual leap — which Covert has dubbed “deep curation” — needed to make it all happen, but he found a way. As Covert points out, no model is perfect, but some are useful. And that is how usefulness, not perfection, became the goal of his work, as he tells fellow bioengineer Russ Altman in this episode of Stanford Engineering’s The Future of Everything podcast.

By , No comments:
Tags ,

UX Copy Sizes: Long, Short, and Micro

Mike's Notes

This definition of copy sizes from NNGroup is great. I am adding it to the Pipi Content Management System Engine (cms) internal schema.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NNGroup
  • Home > pipiWiki > Engines > CMS Engine
  • Home > Repository > Schema > NNGroup > UX Copy Sizes

Last Updated

30/05/2025

UX Copy Sizes: Long, Short, and Micro

By: Taylor Dykes
NNGroup: 16/05/2025

Summary:

Better target user needs by understanding the three sizes of copy: long-form, short-form, and microcopy.

Content terms like long-form, short-form, and microcopy are often used interchangeably, but are ill-defined and don’t mean the same thing. Knowing the differences between these types of copy and when and how to design them effectively will create written information that better supports user needs.

Content vs. Copy: What’s the Difference?

Before discussing different copy lengths, let’s define the difference between content and copy.

  • Content is everything that goes into a digital interface, regardless of media format.
  • Copy is a subcategory of content encompassing all the user-interface text written by the organization (not by the user).

Diagram of digital content types—Copy, Audio, Video, User-generated, and Images—inside a large circle. Film, Print Media, and Television appear outside.


Content is an all-encompassing term that includes copy and all the other elements of digital interfaces, such as videos, audio, and images.

While it might be easy to distinguish between copy and content along media formats, it can be harder to distinguish between user-generated content and copy. Essentially, any content not designed by the publishing platform for that platform is user-generated content.

In this definition, reviews, comments, and social posts all count as user-generated content. For example, an Amazon review is not copy because it is not created by the platform; instead, someone from outside — the user — created this content.

Now that we’ve established the differences between copy and content, let’s review how copy length impacts the user experience.

Long-Form Copy

Long-form copy is 3 or more paragraphs that form a coherent and continuous unit.

Writers should use long-form copy when additional detail, complexity, or context needs to be communicated to the user. When used correctly, the expanded word count allows writers to elaborate and include every detail users might need to know to accomplish their tasks.

When people think of long-form copy, they often think of using it for blog posts, news, or educational articles. However, long-form copy can also be used for:

  • Policy descriptions
  • Product or technical documentation
  • Help and support pages
  • Reports or case studies
  • Product pages
  • About us pages
  • Proposals and grants

Long-form content is becoming increasingly rare online, due to an ever-decreasing user attention span. But it will never go extinct, as it is the only copy type capable of delivering complex, detail-rich information on topics like multistep processes or troubleshooting advanced technical problems. In addition, users sometimes read for a more comprehensive understanding when the topic is significant to them (also called the commitment pattern). Giving bite-sized information in such a situation might create distrust.

Another reason why long-form copy will likely always have a place online is its ability to aid search-engine optimization (SEO). Long-form copy can naturally hold many keywords, increase user engagement time, and assist internal linking, which help improve a site’s SEO.

A multi paragraph page describing a hospital system's history of treating orthopedic conditions, what sets them apart, and their continued research.


This landing page for a hospital system’s orthopedic offerings uses long-form copy to insert keywords (such as Maryland, Washington D.C., and Virginia) to increase its  ranking on the search-engine results page.

Long-form copy doesn’t easily grab user attention. Unlike the other copy lengths, long-form copy requires time, attention, and mental energy to read thoroughly. This factor has caused long-form copy to become increasingly uncommon outside of articles.

To help users quickly get the gist from long-form copy, good content designers and writers include short-form copy and microcopy to format, structure, and break up text. For example, the long-form copy might include microcopy like headings and subheadings, or short-form copy in an accordion’s answer to a frequently asked question. While long-form copy often comprises short-form and microcopy, it still reads as a cohesive unit to users.

Short-Form Copy

Short-form copy is 2–3 paragraphs focused on communicating one main idea.

Short-form copy is used when a single idea or main point needs to be conveyed quickly, often in a way that grabs the user's attention. Writers use short-form copy to help users find information or quickly understand important ideas and messages that, if buried in long-form copy, might be missed.

Some examples of short-form copy include:

  1. Onboarding tutorials
  2. Longer summaries
  3. Product descriptions
  4. Detailed mission statements

Short-form copy has become the default way for communicating information to audiences. Since reading long-form copy requires too much user effort and attention, writers must consider how they might fit detailed information into a short-form format. Strategically breaking up text or organizing it innovatively can communicate a lot of information in scanning-friendly short-form copy.

Page showing the different types of blood donation. Under the headings for two types is a single paragraph and short blurbs of information.


The American Red Cross used short-form copy within cards to structure information that had likely been presented as a long-form article in the past.

Short-form copy is the middle ground between long-form and microcopy; it’s short enough to scan but long enough to convey a whole idea. It won’t overwhelm users but may provide enough information to help them find something or make an informed decision, so they won’t need to read long-form copy on the same topic.

However, UX writers should avoid prematurely defaulting to this happy medium. Even if users are more likely to scan or even read the short-form copy in its entirety, short-form copy won’t help them comprehend the information if the topic’s complexity is better suited for long-form.

Short-form copy is also not a replacement for microcopy, even if it can create a more complete picture of a topic. Users want specific takeaways instantly, and that’s better suited for one-to-two sentence microcopy.

Microcopy

Microcopy is the smallest copy size: fewer than 3 sentences.

Microcopy is used when a writer needs to quickly inform, influence, or encourage interaction for the user’s next step. Because of its size, microcopy is the copy that is most easily processed by users (through scanning or screen-reader voice-over). Good microcopy will prevent errors, encourage clicks, and educate users.

Examples of microcopy include:

  1. Link and button labels
  2. Form-field instructions
  3. Input-control labels
  4. Page titles and meta descriptions
  5. Error messages
  6. Tooltips

Microcopy often makes up most of the written information in the experience. Designers favor microcopy because it allows them to guide users efficiently without disrupting the flow of an interaction. Users appreciate microcopy because it’s easy to skim and scan as they navigate, helping them quickly understand what to do without being overwhelmed by large amounts of text.

The homepage of IBM. There are taglines, buttons, link labels and summaries on this page.


IBM.com:  Each text snippet in this screenshot is an example of microcopy.

While much of the copy in an interface is microcopy, microcopy alone cannot create a complete experience. Microcopy needs other UI elements, images, videos, input controls, and a mix of short- and long-form to create an effective experience. Microcopy isn’t meant to be the primary focus of a website; it’s there to guide, support, and influence users toward the main content or action.

Copy Sizes: In Brief

Long-Form Copy

Definition

  • 3+ paragraphs that form a coherent and continuous unit

When to Use

  • For detailed or complex information
  • When users want more thorough knowledge
  • To aid SEO

Examples

  • Policy descriptions
  • Product or technical documentation
  • Help and support pages
  • Reports or case studies
  • Product pages
  • About us pages
  • Proposals and grants 

Short-Form Copy

Definition

  • 2–3 paragraphs that communicate one main idea 

When to Use

  • For succinctly communicating important and relatively detailed information
  • For breaking down long copy into scannable units

Examples

  • Onboarding tutorials
  • Longer summaries
  • Product descriptions
  • Detailed mission statements

Microcopy

Definition

  • Fewer than 3 sentences

When to Use

  • To guide users in an interface
  • To quickly communicate a critical point

Examples

  • Link and button labels
  • Form field instructions
  • Input control labels
  • Page titles and meta descriptions
  • Error messages
  • Tooltips

Conclusion

There are so many types of text in digital interfaces that it’s easy to confuse their definitions or forget how they differ. Taking the time to learn or refresh the scopes of UX copy can help writers choose the best approach for the experiences they’re designing.

By , No comments:
Tags , , ,

A study in project failure

Mike's Notes

Here is another study into the cause of IT waste.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

26/05/2025

A study in project failure

By: Dr John McManus and Dr Trevor Wood-Harper
British Computer Society: 06/09/2008

Research highlights that only one in eight information technology projects can be considered truly successful (failure being described as those projects that do not meet the original time, cost and (quality) requirements criteria).

Despite such failures, huge sums continue to be invested in information systems projects and written off. For example the cost of project failure across the European Union was €142 billion in 2004.

The research looked at 214 information systems (IS) projects at the same time, interviews were conducted with a selective number of project managers to follow up issues or clarify points of interest. The period of analysis covered 1998-2005 the number of information systems projects examined across the European Union.

Number of IS projects examined within European Union

Rank Sector No. of projects examined
1 Manufacturing 43
2 Retail 36
3 Financial services 33
4 Transport 27
5 Health 18
6 Education 17
7 Defence 13
8 Construction 12
9 Logistics 9
10 Agriculture 6
Total   214

Project value in millions of Euros

Value range in millions (€) Number of projects Percentage(%) Accumulative (%)
0 – 1 51 23.831 23.831
1 – 2 20 9.346 33.177
2 - 3 11 5.140 38.317
3 - 5 33 15.421 53.738
5 - 10 4 1.869 55.607
10 - 20 87 40.654 96.261
20 - 50 6 2.804 99.065
50 - 80 2 0.935 100.000
Totals 214 100.00 100.00

At what stage in the project lifecycle are projects cancelled (or abandoned as failures)?

Prior research by the authors in 2002 identified that 7 out of 10 software projects undertaken in the UK adopted the waterfall method for software development and delivery. Results from the analysis of cases indicates that almost one in four of the projects examined were abandoned after the feasibility stage of those projects completed approximately one in three were schedule and budget overruns.

Project completions, cancellations and overruns

Waterfall method lifecycle stage Number of projects cancelled Number of projects completed Number of projects overrun (schedule and/or cost)
Feasibility None 214 None
Requirements analysis 3 211 None
Design 28 183 32
Code 15 168 57
Testing 4 164 57
Implementation 1 163 69
Handover None 163 69
Percentages 23.8% 76.2%  

Of the initial 214 projects studied 51 (23.8 per cent were cancelled) - a summary of the principal reasons why projects were cancelled is given below. Our earlier research elaborated on the symptoms of information systems project failure in three specific areas: frequent requests by users to change the system; insufficient communication between the different members of the team working on the project and the end users (stakeholders); and no clear requirements definitions. Whilst communication between team and end users was still perceived as an issue within some projects; the top three issues from this study are: business process alignment; requirements management; and overspends.

One notable causal factor in these abandonment's was the lack of due diligence at the requirements phase, an important factor here was the level of skill in design and poor management judgement in selecting software engineers with the right skill sets. Equally the authors found some evidence in poor tool set selection in that end users found it difficult to sign-off design work - in that they could not relate process and data model output with their reality and practical knowledge of the business processes.

Key reasons why projects get cancelled

  • Business reasons for project failure
  • Business strategy superseded;
  • Business processes change (poor alignment);
  • Poor requirements management;
  • Business benefits not clearly communicated or overstated;
  • Failure of parent company to deliver;
  • Governance issues within the contract;
  • Higher cost of capital;
  • Inability to provide investment capital;
  • Inappropriate disaster recovery;
  • Misuse of financial resources;
  • Overspends in excess of agreed budgets;
  • Poor project board composition;
  • Take-over of client firm;
  • Too big a project portfolio.

Management reasons

  • Ability to adapt to new resource combinations;
  • Differences between management and client;
  • Insufficient risk management;
  • Insufficient end-user management;
  • Insufficient domain knowledge;
  • Insufficient software metrics;
  • Insufficient training of users;
  • Inappropriate procedures and routines;
  • Lack of management judgement;
  • Lack of software development metrics;
  • Loss of key personnel;
  • Managing legacy replacement;
  • Poor vendor management
  • Poor software productivity;
  • Poor communication between stakeholders;
  • Poor contract management;
  • Poor financial management;
  • Project management capability;
  • Poor delegation and decision making;
  • Unfilled promises to users and other stakeholders.

Technical reasons

  • Inappropriate architecture;
  • Insufficient reuse of existing technical objects;
  • Inappropriate testing tools;
  • Inappropriate coding language;
  • Inappropriate technical methodologies;
  • Lack of formal technical standards;
  • Lack of technical innovation (obsolescence);
  • Misstatement of technical risk;
  • Obsolescence of technology;
  • Poor interface specifications;
  • Poor quality code;
  • Poor systems testing;
  • Poor data migration;
  • Poor systems integration;
  • Poor configuration management;
  • Poor change management procedures;
  • Poor technical judgement.

What is the average schedule and budget overrun?

In examining the cases it was noted that the average duration of a project was just over 26 months (115 weeks) and the average budget was approximate 6 million Euros, (Table 5). In many instances information on a project being over schedule and over budget will force senior management to act, however, the search for the underlying factors should begin else where in the projects history.

The pattern that emerges from a synthesis of case data is complex and multifaceted. In a few of the of cases examined the project commentary and history was ambiguous; however, once a decision had been made to support a project which was over schedule or over budget the ends usually justified the means irrespective of the viewpoints of individual project managers or stakeholders.

Cost and schedule overruns (N=69)

Projects From Sample 2 (2) 11 (13) 19 (32) 25 (57) 12 (69)
Schedule Overrun  11 weeks 29 weeks 46 weeks 80 weeks 103 weeks
Range Average  Budget + 10% Average  Budget + 25% Average Budget + 40% Average Budget + 70% Average Budget + 90%
Cost Overrun €600,000 €1,500,000 €2,400,000 €4,200,000 €5,400,000

What are the major causal factors contributing to project failure?

Judgements by project stakeholders about the relative success or failure of projects tend to be made early in the projects life cycle. On examination of the project stage reports it became apparent that many project managers plan for failure rather than success. 

If we consider the inherent complexity of risk associated with software project delivery it is not too surprising that only a small number of projects are delivered to the original time, cost, and quality requirements.

Our evidence suggests that the culture within many organisation's is often such that leadership, stakeholder and risk management issues are not factored into projects early on and in many instances cannot formally be written down for political reasons and are rarely discussed openly at project board or steering group meetings although they may be discussed at length behind closed doors.

Despite attempts to make software development and project delivery more rigorous, a considerable proportion of delivery effort results in systems that do not meet user expectations and are subsequently cancelled. In our view this is attributed to the fact that very few organisation's have the infrastructure, education, training, or management discipline to bring projects to successful completion.

One of the major weaknesses uncovered during the analysis was the total reliance placed on project and development methodologies. One explanation for the reliance on methodology is the absence of leadership within the delivery process. Processes alone are far from enough to cover the complexity and human aspects of many large projects subject to multiple stakeholders, resource and ethical constraints.

Although our understanding of the importance of project failure has increased, the underlying reasons still remain an issue and a point of contention for both practitioners and academics alike. Without doubt there is still a lot to learn from studying project failure.

Going back to the research undertaken there is little evidence that the issues of project failure have been fully addressed within information systems project management. Based on this research project failure requires recognition of the influence multiple stakeholders have on projects, and a broad based view of project leadership and stakeholder management.

Developing an alternative methodology for project management founded on a leadership, stakeholder and risk management should lead to a better understanding of the management issues that may contribute to the successful delivery of information systems projects.

By , No comments:
Tags , ,
Subscribe to: Posts (Atom)