== The [[Quality]] Equation ==

== The [[Quality]] Equation ==

[[wikipedia:Quality|quality]] = specification Δ implementation

[[Quality|quality]] = specification Δ implementation

== Minimizing the [[Amoeba]] Effect ==

== Minimizing the [[Amoeba]] Effect ==

Over the time, with new and new releases, regressions occur. The functionality of the code is changing, it starts to do new things and alas, it also stops to do what it used. Of course one can execute the manual test procedures once more with every release, but that is first of all very expensive as people have to try all specified features from all previous releases, and the accuracy of such findings often is not [[good]] enough. As a result the shape of the application code is changing from release to release as [[wikipedia::amoeba|real amoeba]] changes its shape over time. That is why this behaviour is called the [[Amoeba Model]].

Over the time, with new and new releases, regressions occur. The functionality of the code is changing, it starts to do new things and alas, it also stops to do what it used. Of course one can execute the manual test procedures once more with every release, but that is first of all very expensive as people have to try all specified features from all previous releases, and the accuracy of such findings often is not [[good]] enough. As a result the shape of the application code is changing from release to release as [[wikipedia::amoeba|real amoeba]] changes its shape over time. That is why this behaviour is called the [[Amoeba Model]].

== Minimizing the [[Amoeba]] Effect ==

== Minimizing the [[Amoeba]] Effect ==

== Minimizing the [[Amoeba]] Effect ==

== Minimizing the [[Amoeba]] Effect ==

Clearly, the differences between the perfect vision and imperfect real estate are always going to exist. The goal of an [[API]] designer is to minimize them, the less differences between them, the greater will be the chance that the [[API]] user and [[API]] designer are going to understand each other. As [[API]] designed is mostly about communication (see [[The_Motivation_to_Create_an_API|Chapter 2]]) it helps if the [[API]] designer and user talk the same language - for example they know and use the right [[APIDesignPatterns]].

Clearly, the differences between the perfect vision and imperfect real estate are always going to exist. The goal of an [[API]] designer is to minimize them, the less differences between them, the greater will be the chance that the [[API]] user and [[API]] designer are going to understand each other. As [[API]] design is mostly about communication (see [[The_Motivation_to_Create_an_API|Chapter 2]]) it helps if the [[API]] designer and user talk the same language - for example they know and use the right [[APIDesignPatterns]].

The other important direction to tackle the [[Amoeba Model]] differences, is to do testing. At least run some [[SignatureTests]] to guarantee [[BackwardCompatibility|Binary Compatibility]]. Have some [[CodeCoverage]] with automated tests to assert functional compatibility during execution (more in [[Runtime_Aspects_of_APIs|Chapter 11]]).

The other important direction to tackle the [[Amoeba Model]] differences, is to do testing. At least run some [[SignatureTests]] to guarantee [[BackwardCompatibility|Binary Compatibility]]. Have some [[CodeCoverage]] with automated tests to assert functional compatibility during execution (more in [[Runtime_Aspects_of_APIs|Chapter 11]]).

== What does a "[[quality]] of a library" mean? ==

== What does a "[[quality]] of a library" mean? ==

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have a [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have a [[good]] [[performance]]. Almost always we want the application to not crash too often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a [[MapReduce]] script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every project.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a [[MapReduce]] script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every project.

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have a [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have a [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a [[MapReduce]] script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every [[library]]/application.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a [[MapReduce]] script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every project.

Let's include the expectations for an application into one general category - '''specification'''. Let's pretend for a moment the specification is well understood (written down, shared between project participants). That's usually distant, unachievable dream - there are many implicit expectations based on project context, but real architects, real [[UI]] designers, shall be able to prepare such specification. Thus let's assume a '''specification''' describing how our application should look and behave exists.

Let's include the expectations for a certain project into one general category - '''specification'''. Let's pretend for a moment the specification is well understood (written down, shared between project participants). That's usually distant, unachievable dream - there are many implicit expectations based on project context, but real architects, real [[UI]] designers, shall be able to prepare such specification. Thus let's assume a '''specification''' describing how our application should look and behave exists.

== The [[Amoeba Model]] ==

== The [[Amoeba Model]] ==

Let's include the expectations for an application into one general category - '''specification'''. Let's pretend for a moment the specification is well understood (written down, shared between project participants). That's usually distant, unachievable dream - there are many implicit expectations based on project context, but real architects, real [[UI]] designers, shall be able to prepare such specification. Thus let's assume a '''specification''' describing how our application should look and behave exists.

Let's include the expectations for an application into one general category - '''specification'''. Let's pretend for a moment the specification is well understood (written down, shared between project participants). That's usually distant, unachievable dream - there are many implicit expectations based on project context, but real architects, real [[UI]] designers, shall be able to prepare such specification. Thus let's assume a '''specification''' describing how our application should look and behave exists.

== Amoeba Model ==

== The [[Amoeba Model]] ==

The [[Amoeba Model]] is one way to imagine the relation between the specification, that is our expectations and the reality. Here is a picture showing our great vision:

The [[Amoeba Model]] is one way to imagine the relation between the specification, that is our expectations and the reality. Here is a picture showing our great vision:

Over the time, with new and new releases, regressions occur. The functionality of the code is changing, it starts to do new things and alas, it also stops to do what it used. Of course one can execute the manual test procedures once more with every release, but that is first of all very expensive as people have to try all specified features from all previous releases, and the accuracy of such findings often is not [[good]] enough. As a result the shape of the application code is changing from release to release as [[wikipedia::amoeba|real amoeba]] changes its shape over time. That is why this behaviour is called the [[Amoeba Model]].

Over the time, with new and new releases, regressions occur. The functionality of the code is changing, it starts to do new things and alas, it also stops to do what it used. Of course one can execute the manual test procedures once more with every release, but that is first of all very expensive as people have to try all specified features from all previous releases, and the accuracy of such findings often is not [[good]] enough. As a result the shape of the application code is changing from release to release as [[wikipedia::amoeba|real amoeba]] changes its shape over time. That is why this behaviour is called the [[Amoeba Model]].

== Minimizing Amoeba Effect ==

== Minimizing the [[Amoeba]] Effect ==

Clearly, the differences between the perfect vision and imperfect real estate are always going to exist. The goal of an [[API]] designer is to minimize them, the less differences between them, the greater will be the chance that the [[API]] user and [[API]] designer are going to understand each other. As [[API]] designed is mostly about communication (see [[The_Motivation_to_Create_an_API|Chapter 2]]) it helps if the [[API]] designer and user talk the same language - for example they know and use the right [[APIDesignPatterns]].

Clearly, the differences between the perfect vision and imperfect real estate are always going to exist. The goal of an [[API]] designer is to minimize them, the less differences between them, the greater will be the chance that the [[API]] user and [[API]] designer are going to understand each other. As [[API]] designed is mostly about communication (see [[The_Motivation_to_Create_an_API|Chapter 2]]) it helps if the [[API]] designer and user talk the same language - for example they know and use the right [[APIDesignPatterns]].

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have a [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have a [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a map reduce script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every [[library]]/application.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a [[MapReduce]] script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every [[library]]/application.

Let's include the expectations for an application into one general category - '''specification'''. Let's pretend for a moment the specification is well understood (written down, shared between project participants). That's usually distant, unachievable dream - there are many implicit expectations based on project context, but real architects, real [[UI]] designers, shall be able to prepare such specification. Thus let's assume a '''specification''' describing how our application should look and behave exists.

Let's include the expectations for an application into one general category - '''specification'''. Let's pretend for a moment the specification is well understood (written down, shared between project participants). That's usually distant, unachievable dream - there are many implicit expectations based on project context, but real architects, real [[UI]] designers, shall be able to prepare such specification. Thus let's assume a '''specification''' describing how our application should look and behave exists.

== What does a "[[quality]] of a library" mean? ==

== What does a "[[quality]] of a library" mean? ==

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have a [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a map reduce script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every [[library]]/application.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a map reduce script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every [[library]]/application.

== What does a "[[quality]] of a library" mean? ==

== What does a "[[quality]] of a library" mean? ==

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]], natural work flow. Others may ask for it be acceptably fast - e.g. have [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

There are many possible answers to the question ''When does an application have [[good]] [[quality]]?'' Depending on one's standpoint the application can be requested to have a slick [[UI]] with natural work flow. Others may ask for it be acceptably fast - e.g. have [[good]] [[performance]]. Almost always we want the application to not crash often. For some [[modular]]ity and extensibility is the essential system feature. When talking about [[libraries]]/applications with an [[API]] it may be important to have good [[documentation]]. Externally facing systems are often requested to be secure.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a map reduce script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every [[library]]/application.

All of the above are great features, but it should be pointed out that ''not all of them are really needed every time''. Security is extremely important when writing an internet wide end point. On the other hand, nobody cares about security when writing a map reduce script. User experience needs to be smooth for applications with [[UI]], but it is completely unimportant for a [[Linux]] kernel module. The ''set of expectations is different'' for every [[library]]/application.