tag:blogger.com,1999:blog-36052773078680779482024-02-10T13:50:34.875-08:00Accelerated DevelopmentThe cold hard facts about software development, i.e. propositions are backed up from facts from over 15,000 projects. Many truths are counter-intuitive to the current beliefs. This blog is oriented towards beginner and intermediate developers and product managers. (dsm@dalipmahal.com)Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.comBlogger69125tag:blogger.com,1999:blog-3605277307868077948.post-50428064394762849612019-06-09T12:12:00.000-07:002019-06-09T13:34:06.320-07:00Waterfall is for Losers?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://media.cntraveler.com/photos/571945e380cf3e034f974b7d/16:9/w_1440,c_limit/waterfalls-Seljalandsfoss-GettyImages-457381095.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="450" data-original-width="800" height="112" src="https://media.cntraveler.com/photos/571945e380cf3e034f974b7d/16:9/w_1440,c_limit/waterfalls-Seljalandsfoss-GettyImages-457381095.jpg" width="200" /></a></div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTdcl0CtKXsehWZjNVWn9d_Rd9Zx7fzxwuGcbIJzCk5VVSciIAQqVUSUTCkg9xLmYNVKgoML8rsjxtOA7kX972vPLgrkyESx9S8c1EO1k2d457kdPUiRySmFuXD6TraNb8eKgB2yJKbEQ/s1600/Loser%2C+small.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="135" data-original-width="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTdcl0CtKXsehWZjNVWn9d_Rd9Zx7fzxwuGcbIJzCk5VVSciIAQqVUSUTCkg9xLmYNVKgoML8rsjxtOA7kX972vPLgrkyESx9S8c1EO1k2d457kdPUiRySmFuXD6TraNb8eKgB2yJKbEQ/s1600/Loser%2C+small.png" /></a><br />
Perhaps that is a bit harsh, but in the question of whether <b>Agile</b> or <b>Waterfall</b> is best, the reality is that Agile ends up being multiple small waterfall cycles. So you end up doing Waterfall in pieces.<br />
<div>
<br /></div>
<div>
All projects are composed of a set of <b>tasks</b>, typically executed by multiple people. Within your set of tasks, some are <b>dependent</b> on others. In particular we can never get away from the fact that to implement any single requirement, we need to analyse the requirement (what), design the solution (how), code the solution (execute), and test the result.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.justgo.travel/wp-content/uploads/2018/01/nelson-falls-tasmania-australia.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="533" data-original-width="800" height="133" src="https://www.justgo.travel/wp-content/uploads/2018/01/nelson-falls-tasmania-australia.jpg" width="200" /></a></div>
<div>
So any <b>iterative and incremental </b>project, i.e. Agile, Scrum, RAD, XP, etc. Is really a series of small waterfalls. The difference is that between the waterfalls we have sandwiched requirements, analysis, design, and coding which gives us the ability to change direction when we need to.</div>
<div>
<br /></div>
<div>
Note: If you never need to change direction (which is not often :-)) then Waterfall is a <b>viable</b> option. Waterfall makes the most sense in projects where there is little to no requirements or technical uncertainty<sup>*</sup>, e.g. reimplementing a system with experienced developers in a new technology where the use cases for the previous system are not changing.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghBmTzNYmf5ldE7GAQUDWsoG4Z_kuJzl5cNCPyljsp83Q17mnakV30kBqN7XGrROGvnI3UVL5i9ytRTBXB3LGOgpkRgp0mfO3ZOZpKiqJ4y9x-RaLzOnYsQ2vANlB6zk-79xfQHxq7yEI/s1600/Waterfall.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="217" data-original-width="1600" height="43" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghBmTzNYmf5ldE7GAQUDWsoG4Z_kuJzl5cNCPyljsp83Q17mnakV30kBqN7XGrROGvnI3UVL5i9ytRTBXB3LGOgpkRgp0mfO3ZOZpKiqJ4y9x-RaLzOnYsQ2vANlB6zk-79xfQHxq7yEI/s320/Waterfall.png" width="320" /></a></div>
<div>
The typical waterfall project assumes the above picture, that all requirements can be done then all design all coding and then all testing. It is based on a 1960's <b>factory</b> mentality that code can be assembled like a car on an assembly line.</div>
<div>
<br /></div>
<div>
Waterfall only works if the amount of rework in any phase is <b>immaterial</b> and does not materially affect the length of the project. Typically this is not true. In the presence of requirements uncertainty, requirements need to be revisited many times. Often, missing or inconsistent requirements will cause scope to change requiring change requests in the process.</div>
<div>
<br /></div>
<div>
All <b>change requests</b> will affect the project schedule.</div>
<div>
<br /></div>
<div>
In the presence of technical uncertainty, design needs to be <b>revisited</b> many times. Often when using newer APIs the API is not documented or even worse, the code mechanism from the creator/vendor simply does not work and requires technical work arounds that materially affect the project schedule.</div>
<div>
<br /></div>
<div>
This will create a change request that will affect the <b>project schedul</b>e.</div>
<div>
<br /></div>
<div>
An agile project builds requirements and design into every sprint. This allows you to <b>change directions</b> when either requirements or technical decisions are uncertain.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJfSVR2mY0XBb4sof2KqN0ZENVdUF9ZDUimaCktCipnTJ0hiWBMyp_7H-H5tgwNF9DYIa8NyIN_DleBECJ3tUdVxbgx_jbio4OvWF-CXmwAZjR_Ntn0l5zNh_1sli8EnRDZDbihzCWwX4/s1600/Agile+process.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="217" data-original-width="1600" height="43" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJfSVR2mY0XBb4sof2KqN0ZENVdUF9ZDUimaCktCipnTJ0hiWBMyp_7H-H5tgwNF9DYIa8NyIN_DleBECJ3tUdVxbgx_jbio4OvWF-CXmwAZjR_Ntn0l5zNh_1sli8EnRDZDbihzCWwX4/s320/Agile+process.png" width="320" /></a></div>
<div>
This is the series of small waterfalls -- you are still doing Waterfall, but in an Agile way.</div>
<div>
<br /></div>
<div>
When you add up all the sprints of a project, you will realize that you have done the same project (i.e. the work is the work), but you have <b>sliced</b> it up differently.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguYB1SP3DNp2SrRBfvQphZpkceUu0lU-3p6S76AbOF16SohceZzH6j9RPEdaevcwTcV-TjrlJOP7-6etiVuQW7zAi8nySVwE6nK-iGlwggLKF-ru-zPNgPNdNqmf3szSfT5_rbee0FgxA/s1600/Agile+process+in+Waterfall.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="433" data-original-width="1600" height="86" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguYB1SP3DNp2SrRBfvQphZpkceUu0lU-3p6S76AbOF16SohceZzH6j9RPEdaevcwTcV-TjrlJOP7-6etiVuQW7zAi8nySVwE6nK-iGlwggLKF-ru-zPNgPNdNqmf3szSfT5_rbee0FgxA/s320/Agile+process+in+Waterfall.png" width="320" /></a></div>
<div>
So it is not a <b>question</b> of whether you will be doing Waterfall or not. It is a matter of what is the sprint cycle that will support the requirements and technical uncertainty of your project. If your project has little to no uncertainty, then your sprint cycle is the entire project.</div>
<div>
<br /></div>
<div>
If your project has requirements or technical uncertainty, then sprint cycles of 2-3 weeks are ideal.</div>
<br />
<sup>*</sup>Note: <i>Similar to requirements and technical uncertainty are projects where there are significant dependencies on client interaction, so schedule uncertainty can also drive the need for agile project management.</i><br />
<br class="Apple-interchange-newline" />
<hr />
<span style="font-size: 32px;">Other articles in the "Loser" series</span><br />
<div style="text-align: right;">
</div>
<br />
Want to see more sacred cows get tipped? Check out<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://i2.wp.com/farm1.static.flickr.com/208/507425115_c2b6374f9a_o.jpg?zoom=2" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="273" data-original-width="360" height="151" src="https://i2.wp.com/farm1.static.flickr.com/208/507425115_c2b6374f9a_o.jpg?zoom=2" width="200" /></a></div>
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/comments-are-for-losers.html" target="_blank">Comments are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/04/defects-are-for-losers.html" target="_blank">Defects are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/07/debuggers-are-for-losers.html" target="_blank">Debuggers are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/effectiveness-first-efficiency-second.html" target="">Efficiency is for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/01/developers-are-ones-who-inject-defects.html" target="_blank">Testing departments are for Losers</a></li>
</ul>
<i>Make no mistake, I am the biggest "Loser" of them all. I believe that I have made every mistake in the book once :-)</i></div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-81159131947681875582017-01-06T11:38:00.001-08:002017-01-06T11:38:24.673-08:00What is software architecture?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzccpu5wYJUmiauIa0lT4PPUswlAwW8BnoefMnkfmrdFe60dRFfqINl6RsKVJU6DmrCONXWC8K7trNOwXvxxMbUOWiimMlTxfqXSUlWtBz3V1AWZth5_S44O3TlGB1k_4gIypWEqJyiAs/s1600/Wordle+software+architecture.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzccpu5wYJUmiauIa0lT4PPUswlAwW8BnoefMnkfmrdFe60dRFfqINl6RsKVJU6DmrCONXWC8K7trNOwXvxxMbUOWiimMlTxfqXSUlWtBz3V1AWZth5_S44O3TlGB1k_4gIypWEqJyiAs/s200/Wordle+software+architecture.jpg" width="195" /></a></div>
<b>What is software architecture?</b> In the previous article "What is architecture?" we stated that architecture is about:<br />
<ul style="text-align: left;">
<li>Structural elements</li>
<li>Connective elements</li>
</ul>
<div>
Let us talk about these with regard to a software system. In our next article we'll talk about <b>good and bad architecture</b>.</div>
<h2 style="text-align: left;">
Structural elements</h2>
Structural elements in software are layers that support other layers in the system:<br />
<ul style="text-align: left;">
<li>the language libraries are built on the functionality provided by the O/S</li>
<li>the functionality of the software product is built on the language libraries</li>
<li>3rd part libraries that you are using are built on the previous 2 layers</li>
<li>your code is built on all the previous layers</li>
</ul>
<br />
So any program you build has at least the following structural elements:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDu1VIbxebt4gvsmdeylJWEtwa62R5ktJafQX63amZ5XpDGQlK5zCKa-439AD6BZor7NihRsV0oM5T9AX6QLkIj-JwH9iPmIwpRs6Rt08WUgzykIqprWVMjfRJX9_0sgj5AR8grZjKMEE/s1600/Software+Architecture%2C+Basic.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="340" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDu1VIbxebt4gvsmdeylJWEtwa62R5ktJafQX63amZ5XpDGQlK5zCKa-439AD6BZor7NihRsV0oM5T9AX6QLkIj-JwH9iPmIwpRs6Rt08WUgzykIqprWVMjfRJX9_0sgj5AR8grZjKMEE/s640/Software+Architecture%2C+Basic.png" width="640" /></a></div>
<div style="text-align: left;">
In a well designed system, your code will also break into layers specific to the application that you are building. Each layer ideally only depends on layers underneath it, otherwise you will have circular references; asignal that there is a challenge or that something is wrong. </div>
<h2 style="text-align: left;">
Connective elements</h2>
Every software system has connective elements that communicate across the different layers. Often 3rd party libraries are shared services that provide core services like data structures (XML, JSON, etc), logging, debugging, and other services.<br />
<br />
Inside your code you will also have shared services that are used by every layer, this is diagrammed as follows:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZKIPpMDo-zBRcP4sJc5UgieDQRmcztGbmrT2Pa1bEj5bg7Oq_pWi5wi6msruLFC1Ogf9rjQKv2dVQ1pkg9W45ibKgkpOlQs4W5vhgTTfQJz9GWoVoGbqbsbr_0mUWwJI_Lq_KpaNetsQ/s1600/Software+Architecture%2C+Services.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="282" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZKIPpMDo-zBRcP4sJc5UgieDQRmcztGbmrT2Pa1bEj5bg7Oq_pWi5wi6msruLFC1Ogf9rjQKv2dVQ1pkg9W45ibKgkpOlQs4W5vhgTTfQJz9GWoVoGbqbsbr_0mUWwJI_Lq_KpaNetsQ/s400/Software+Architecture%2C+Services.png" width="400" /></a></div>
Where layer 1, 2, ..., N represent the layers in your code and the share services are shown vertically as they cut across all the layers. Layer N represents the UI layer of the system and the functionality at that layer depends on all the layers below it.<br />
<h2 style="text-align: left;">
Generalizing Architecture</h2>
When people are talking about software architecture, they are not just talking about the structure of the code. Often people are talking about the machines and O/S components as well. So for example when people are talking about the LAMP architecture they are talking about:<br />
<br />
<ul style="text-align: left;">
<li>The O/S -- i.e. Linux</li>
<li>The web server -- Apache, running on Linux</li>
<li>The database -- MySql, running on Linux,</li>
<li>The code -- PHP running on the MySql database using services from the O/S</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2Ic6xnsxQwiaUxknWPTfg7YmsSHQCqgDqARGHW_WXFb_-Kv8OElGl2-7qoNmvFi9yh12Q7AXZAVVF1U3gPNCu7UDU1KPq62cpz7rZYCm8RH9MTu9t7IDma3BxVDRTZR7h-3mzOGH24So/s1600/Software+Architecture%2C+LAMP.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="140" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2Ic6xnsxQwiaUxknWPTfg7YmsSHQCqgDqARGHW_WXFb_-Kv8OElGl2-7qoNmvFi9yh12Q7AXZAVVF1U3gPNCu7UDU1KPq62cpz7rZYCm8RH9MTu9t7IDma3BxVDRTZR7h-3mzOGH24So/s400/Software+Architecture%2C+LAMP.png" width="400" /></a></div>
<div>
Note: The PHP layer is further broken down like the diagram above in the <b>Structural Elements</b> section.</div>
<div>
<br /></div>
<div>
The LAMP architecture involves structural elements. Connective elements are simply the ones created inside the PHP layer or generally provided by the O/S.<br />
<br />
So when relevant, architecture includes:<br />
<br />
<ul style="text-align: left;">
<li>The O/S</li>
<li>All support services, i.e. webserver, database, etc.</li>
<li>The high level applications written by you or a 3rd party</li>
</ul>
<h2 style="text-align: left;">
General Software Architecture</h2>
<div>
For the structural elements of software we are taking about layers. Those layers can be relative to the O/S such as how the O/S communicates with support services (web servers, databases, etc) or how your applications communicate with support services and the O/S.</div>
<div>
<br /></div>
<div>
Within your application there are different layer interactions, there is 1) how your base layers are built on the APIs of your language and the 3rd party libraries that you have installed, and 2) how you have broken up your layers to communicate with the different parts of your software.</div>
<div>
<br /></div>
<div>
The main structural elements of any model-view-controller (MVC) program looks somewhat like this:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmAp5uEanjcfNNfDLx1bjQuYja5lVt93FJBDgVlDx9BRmVscVX6eGvWqhSW1SDWwN4G4Kr2TzV-x394VQhSPLSJ1PxYPUoQX6Xtxxt9ITd6jzertfMDubaOy6coA6XydgqREzUuZXUZhE/s1600/Software+architecture%2C+MVC.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="95" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmAp5uEanjcfNNfDLx1bjQuYja5lVt93FJBDgVlDx9BRmVscVX6eGvWqhSW1SDWwN4G4Kr2TzV-x394VQhSPLSJ1PxYPUoQX6Xtxxt9ITd6jzertfMDubaOy6coA6XydgqREzUuZXUZhE/s320/Software+architecture%2C+MVC.png" width="320" /></a></div>
<div>
<ul style="text-align: left;">
<li>The model layer a.k.a. business layer is built on 3rd party APIs and O/S APIs</li>
<li>The view layer a.k.a. GUI layer is built on 3rd party GUI APIs</li>
<li>The data layer is build on database APIs</li>
</ul>
<div>
All of the APIs that you are using are based on the standard APIs of the language that you are using.</div>
</div>
<h3 style="text-align: left;">
Implications</h3>
<div>
<ul style="text-align: left;">
<li>Changing languages requires that every layer above it be reconsidered</li>
<ul>
<li>This means that if you change languages and some 3rd party API must be changed then the layer above also needs to be changed</li>
</ul>
<li>Strict separation in layers means that you can change a 3rd party API and only a single layer of the MVC system is affected</li>
<ul>
<li>Often developers color between the lines and a change of a 3rd party library causes quite a bit of pain as the layer infractions are found</li>
</ul>
<li>Not having enough of a business layer will be problematic because it is one of the main separating structures between your view/GUI and data layers.</li>
<ul>
<li>People discover lacking business layers when they change their database APIs or databases and have the problems propagate all the way through the GUI</li>
<li>Often when business functionality is built into the model/GUI layer then that functionality is lost and needs to be recoded when a new GUI API is used</li>
</ul>
</ul>
<h2 style="text-align: left;">
Connective elements</h2>
</div>
<div>
Connective software elements are used to shuttle data between the structural layers of the system. These connective elements are generally available everywhere (although they can be limited to a few layers).</div>
<div>
<br /></div>
<div>
Easily understood connective elements are those used in debugging and logging. These elements are available universally, e.g. debugging and logging routines can be made available in all layers without worrying about layer dependency.<br />
<br />
Other connective elements are most easily recognized because they are routines shared across layers of the architecture. More specifically, they are the libraries/modules that are included into multiple layers of the program.</div>
</div>
<hr />
<br />
So now we have defined what structural and connective elements are in software, next we describe what it means to have <b>good architecture</b> and <b>bad architecture</b>.</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-64702546317773130072016-12-08T13:49:00.000-08:002017-01-09T08:51:24.306-08:00What is architecture?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixR9PrbKEif-s2voetPYmdyvIUOwmJLUjTi4IszYnBc7cDqL7IHRAMmIo5xjQGHz60jAq9dmvtblQTEBIOYAb3nTmdTNJBD8LEiLnwu4qIUZUoBYKbZKYRNbKUDS6WvAwxEtm08SFN5Xs/s1600/939140-architecture-photography-gallery.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixR9PrbKEif-s2voetPYmdyvIUOwmJLUjTi4IszYnBc7cDqL7IHRAMmIo5xjQGHz60jAq9dmvtblQTEBIOYAb3nTmdTNJBD8LEiLnwu4qIUZUoBYKbZKYRNbKUDS6WvAwxEtm08SFN5Xs/s200/939140-architecture-photography-gallery.jpg" width="200" /></a></div>
On a regular basis we hear people talk of good and bad architecture, but what is <b>architecture</b>? <br />
<br />
Before I describe software architecture, let's see if we can come to an agreement of what architecture is. What are the components of architecture, and what value does architecture have.<br />
<br />
<div>
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.eoxtechnologysolutions.com/images/uploads/slideshow/architecture.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.eoxtechnologysolutions.com/images/uploads/slideshow/architecture.jpg" height="125" width="200" /></a></div>
Architecture provides the <b>structural</b> and <b>connective framework</b> required for a system of components to function. Architecture is specific to a context, good architecture for a software system is different from that of a car or a building. <br />
<br />
Architecture in general is <b>not visible</b>, it is present in the system but under other visible design components. Before a discussion of software architecture, it would be best to describe architecture using physical objects.</div>
<div>
<h2 style="text-align: left;">
Architectural Elements</h2>
Architecture involves two elements:<br />
<ol style="text-align: left;">
<li>Structure</li>
<li>connective elements. </li>
</ol>
Let's look at these two elements with respect to a building.</div>
<div>
<br /></div>
<div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://hd.wallpaperswide.com/thumbs/modern_architecture-t2.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://hd.wallpaperswide.com/thumbs/modern_architecture-t2.jpg" height="129" width="200" /></a></div>
<b>Structure</b> for a building involves the foundation and the pieces that provide support to the entire building; it is the skeleton of the building. If a building has an interesting shape it is because underneath the framework of rebar and concrete support the shape.<br />
<br />
<b>Connective elements </b>can be structural, but they provide a way of linking different structural components for the purposes of transporting something. Connective elements in a building transport air, water, and electricity.<br />
<br /></div>
</div>
<div>
The structural capability of the framework will dictate how high a building can go; generally speaking architecture determines <b>size</b>. If the building has a framework of rebar and concrete that will support a 10 story structure, it will be difficult to add additional floors over 10 easily. Adding additional floors will require effort expended to reinforce the existing structural strength of the building</div>
<div>
<b><br /></b></div>
<div>
<a href="http://farm5.static.flickr.com/4058/4493189011_6736a717d2_m.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><b><img border="0" src="http://farm5.static.flickr.com/4058/4493189011_6736a717d2_m.jpg" height="200" width="150" /></b></a><br />
If a connective element is missing then adding it will be expensive. For example, old brick buildings often didn't plan for plumbing or electricity. If this element is added afterwards, then it will be much more expensive to put in.</div>
<div>
<br /></div>
<div>
If plumbing is added afterwards then you will see the plumbing running outside the walls. This can lead to problems if the building experiences sub-zero weather. </div>
<div>
<br /></div>
<div>
It is similarly inconvenient to add electricity or air-conditioning to a building which has not had these connective elements designed into the building when it was built.<br />
<br />
For comparison purposes, let's look at architecture in a couple of contexts:<br />
<table border="1">
<tbody>
<tr valign="top">
<th>Object</th>
<th>Structural component</th>
<th>Connective elements</th>
</tr>
<tr valign="top">
<td>Building</td>
<td><ul>
<li>Steel frame</li>
<li>Concrete</li>
<li>Bricks</li>
</ul>
</td>
<td><ul>
<li>Plumbing</li>
<li>Electrical system</li>
<li>HVAC system</li>
<li>Elevator</li>
<li>Emergency stairwell </li>
</ul>
</td></tr>
<tr valign="top">
<td>Car</td>
<td><ul>
<li>Chasis</li>
<li>Tires</li>
</ul>
</td>
<td><ul>
<li>Drive train</li>
<li>Steering column</li>
<li>Gas conduits</li>
<li>Electrical system</li>
<li>HVAC system</li>
</ul>
</td></tr>
</tbody></table>
<h2>
Architecture and Visibility</h2>
In the two examples above, several things about architecture stand out:<br />
<ol style="text-align: left;">
<li>Structural components are generally hidden unless they are functional</li>
<li>Connective elements are covered up in the final object</li>
</ol>
<div>
So for a building the structural element of the steel frame is invisible hidden under finishing elements. But there are cases where we see concrete or brick walls exposed. Structural elements are generally not attractive and so we put in extra effort (i.e. cost) to hide the structural elements. Sometimes in the case of concrete or brick walls we will leave them exposed because the visual need to hide these elements are not there, i.e. a warehouse.</div>
<div>
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://cdn.homeadvisor.com/files/costguide/task/images/clean-a-sewer-line_300_200.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://cdn.homeadvisor.com/files/costguide/task/images/clean-a-sewer-line_300_200.jpg" height="132" width="200" /></a></div>
Connective elements are almost always hidden. The sight of electrical wires, plumbing, or HVAC tubes is not aesthetically pleasing and we generally hide these elements. If we are hiding a connective element, they are cheapest to put in when an object is being created the first time. <br />
<h4 style="text-align: left;">
Cost of Fixing Hidden Connective Elements</h4>
Repairing a hidden connective element is expensive. For example, fixing plumbing and electrical wires in a house are expensive depending on how hard it is to access the connective element.<br />
<br />
Adding a connective element after the fact is much more expensive and much less attractive. There are brick buildings that were built prior to indoor plumbing and electricity being available. A good example of these buildings are the residences at Harvard or old brick warehouses that are now office space. In the case of the Harvard residences the plumbing runs outside the residences and due to the winter weather in Boston, is subject to freezing. Adding electricity to a brick warehouse involves running metal conduits inside the walls; since they are exposed, they are subject to water accidents.</div>
<div>
<h4 style="text-align: left;">
Visible Structural Elements</h4>
</div>
<div>
In the case of a car the tires are a structural element, but they are exposed to view. This is why effort goes into making the tires as attractive as possible, i.e. white wall tires, decorative hub caps, etc.</div>
<h2>
Purpose of Architecture</h2>
Once the architecture is set it determines two things:<br />
<ol style="text-align: left;">
<li>The size of an object</li>
<li>The functional capabilities of the object</li>
</ol>
<div>
As previously mentioned, the structural architecture of a building will dictate its maximum size and the connective elements will outline its capabilities. Connective elements are always about functional capabilities.</div>
<div>
<br /></div>
<div>
The purpose of structural architecture is to partition an object into sub-components that are independent and can be designed separately. For example, in a building, the structural architecture allows you to subsequently design each of the apartments separately without worrying about how the design of one room affects another.</div>
<div>
<br /></div>
<div>
For a car, the main structural element of the chassis allows you to design the following sub-components separately:</div>
<div>
<ul style="text-align: left;">
<li>engine</li>
<li>doors</li>
<li>lights</li>
<li>seats</li>
</ul>
<div>
By allowing sub-components to be designed separately we subdivide a problem (i.e. divide-and-conquer), which reduces the complexity of overall design. It allows separate teams to work on the sub-components. Good architecture facilitates strong polymorphism in the sub-components.</div>
</div>
<div>
<br /></div>
<div>
In an apartment, each apartment can be designed differently and by different people. In a car, the engine can be designed by one group of people different from that designing the doors, lights, or other part of the car.</div>
<div>
<br /></div>
<div>
The connective components in each object either: 1) provides a shared service that is accessible to multiple components, or 2) provides a coordination of sub-components to achieve a higher level function.<br />
<br />
Electricity, plumbing, and HVAC are all examples of shared services that are available to an entire building. The usage of electricity in one room does not dictate the usage of electricity in another room, however, aggregate usage of electricity is sized by the architecture.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://nitoautogas.com/upload/system_lpi.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://nitoautogas.com/upload/system_lpi.png" height="200" /></a></div>
Elevators for a building and steering columns and the gas system of a car are examples of components that are coordinated across multiple levels of the object. They provide an overall functionality when all of the sub-components coordinated are functioning.<br />
<br />
In general, if one of the sub-components is not functioning then the entire set of coordinating objects will fail to function. For a car, if any component in the diagram fails then the engine itself will fail.<br />
<br />
<h2 style="text-align: left;">
Summary</h2>
</div>
</div>
<div>
In any object composed of multiple sub-objects there is architecture. Architecture provides two different but related functions that is:</div>
<div>
<ol style="text-align: left;">
<li>Structural components</li>
<li>Connective elements</li>
</ol>
<div>
The architecture of an object dictates how large it can be and determines how separately each sub-component can be designed.</div>
</div>
<div>
<br /></div>
<div>
This article focused on physical objects, the next article will focus on <b>software architecture</b>.</div>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0Toronto, ON, Canada43.653226 -79.38318429999998243.2856095 -80.028631299999986 44.020842499999993 -78.737737299999978tag:blogger.com,1999:blog-3605277307868077948.post-11144307662559759392016-10-07T10:43:00.000-07:002017-01-09T08:51:24.161-08:00Why Outsourcing Fails<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigksHuXVdzzkJbxDETjRB1MOwVF_Hi-5QexKHT-daV5EtaSddz6rQJMp5E8texqVQCHmrqGSq5kw7TiK1A85TnNrAZtVBjp9j2_e8XUMt4yX0BSn3xr7auF347iJROuQf7_Y84fscYO2g/s1600/Outsourcing.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="347" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigksHuXVdzzkJbxDETjRB1MOwVF_Hi-5QexKHT-daV5EtaSddz6rQJMp5E8texqVQCHmrqGSq5kw7TiK1A85TnNrAZtVBjp9j2_e8XUMt4yX0BSn3xr7auF347iJROuQf7_Y84fscYO2g/s640/Outsourcing.png" width="640" /></a></div>
<br />
Every year, we see corporations outsource operations only to pull back back some, if not all, of the operations. When this happens, the cost of pulling back operations or splitting things over multiple countries can leave you with significant operational issues and similar or worse costs.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKGoO6HafE01bKnJEqUoMjAiFi8carqGr-xTDrQ-snJgDJYw4eMY9lKLqgmlRmUjvD9hD2bqIpn6xzOEn_8UUih5kPerTUXREUqypcyQ6rCdnpF71IFL5Kj0WV29OXTmZ16MVwKzyDyqY/s1600/Hammond.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="183" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKGoO6HafE01bKnJEqUoMjAiFi8carqGr-xTDrQ-snJgDJYw4eMY9lKLqgmlRmUjvD9hD2bqIpn6xzOEn_8UUih5kPerTUXREUqypcyQ6rCdnpF71IFL5Kj0WV29OXTmZ16MVwKzyDyqY/s200/Hammond.png" width="200" /></a></div>
<span id="goog_924586044"></span><span id="goog_924586045"></span>Successful corporations understand the need to control costs in operations. The "<b><i>spare no expense</i></b>" philosophy of John Hammond in Jurassic Park is a one way ticket to disaster.<br />
<br />
But, a focus on cost reduction is what leads corporations to face-fault when they outsource.<br />
<br />
Corporations are seduced by the idea of potentially cutting costs dramatically; why pay expensive resources to do repetitive things when overseas people can do the same work for pennies?<br />
<br />
The cardinal rule when outsourcing is:<br />
<br />
<span style="color: yellow; font-size: large;"><i>Only operations that you completely understand and control can be outsourced </i></span><br />
<br />
To understand operations is to understand the costs of exceptions as well as how they are processed and escalated. Local resources deal efficiently with exceptions because they have informal relationships in the organization and use them to get things done efficiently; those relationships are not available to outsourced resources.<br />
<br />
When operations gets outsourced, not only do foreign employees not understand how to deal with exceptions but also:<br />
<br />
<ul style="text-align: left;">
<li>They are often in another time zone </li>
<li>They don't have full access to local resources </li>
<li>They don't know who to contact inside the corporation </li>
<li>They don't understand local business rules </li>
<li>The network configuration can make it impossible to communicate properly </li>
</ul>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEje1sdE4oYrrhZirjjQuGZ9GAZL3J55OhmEunrVTzfIMFFjai-UjJOpq2xBB1bodK5oYmpHDEfkOXpHzs-CcdNrAjF1dy6a-W3WBCCwfhrFVGa4wqqxIVK62mmCX1yLaeJecgLSD1sn8EQ/s1600/eniac.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="106" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEje1sdE4oYrrhZirjjQuGZ9GAZL3J55OhmEunrVTzfIMFFjai-UjJOpq2xBB1bodK5oYmpHDEfkOXpHzs-CcdNrAjF1dy6a-W3WBCCwfhrFVGa4wqqxIVK62mmCX1yLaeJecgLSD1sn8EQ/s200/eniac.png" width="200" /></a></div>
Understanding an operational function means that you capture all details, including exceptions, in your information systems. Often, legacy information systems capture exception information as unstructured fields (i.e. memo fields) and off shore resources will not understand this.<br />
<br />
99% of your operations might be straight forward, but the 1% of exceptions can at best lead to longer implementation times. Best case scenario is that you will look bad to your customers and at worst, it will kill your bottom line.<br />
<br />
If your information systems contain exception information in a structured way then at least you can eventually train foreign resources to resolve them. But unless exception information is captured so you can control it (i.e. not in general text fields) then it is the same thing as not having it.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigBl_Iberj0QccLfuFJwW2-luhoNf2ukeVXC5caFWQVCbuZ01-xwR2Iz2C1HPvtDKuWzC3GCg5TVmQJXsdMDSeWvepL32PR3o89qmwHr-IlH4OBBZ9LVWTMAjJLUI0XTsuUsdyShW8f0I/s1600/Performance.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigBl_Iberj0QccLfuFJwW2-luhoNf2ukeVXC5caFWQVCbuZ01-xwR2Iz2C1HPvtDKuWzC3GCg5TVmQJXsdMDSeWvepL32PR3o89qmwHr-IlH4OBBZ9LVWTMAjJLUI0XTsuUsdyShW8f0I/s200/Performance.jpg" width="200" /></a></div>
When outsourced resources are under strict performance guidelines, they will do anything to clear their work queues. This often involves kicking back work they perceive as an exception as improperly specified; they will claim 'garbage in, garbage out'.<br />
<br />
This will result in miscommunications and longer lead times to implement your services. Not only will delivery times, and errors go up, and your customers will get mad.<br />
<br />
By the time you have fired the local employees, all the knowledge of the function has left the building and you are left with a broken system.<br />
<br />
Key questions to get answers to:<br />
<br />
<ul style="text-align: left;">
<li>What does each exception in operations cost? </li>
<li>How often do they happen? </li>
<li>Can the information systems record exceptions in a way that you can track and control them? </li>
<li>Are the mechanisms that local resources use to resolve exceptions be used by outsourced resources? </li>
</ul>
<br />
If you don't have a clear answer to each of these questions then outsourcing is likely to be a disaster. When you have a clear answer to the 3 questions and understand how you will address each exception then you will have much more success outsourcing.</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-39527438381016766332016-08-10T14:19:00.000-07:002017-01-09T08:51:24.238-08:00Project failure is due to bad requirements<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://static1.squarespace.com/static/503d4284e4b076ac5ff20569/t/54c1ddfae4b03be870fcb9ab/1421991420775/" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://static1.squarespace.com/static/503d4284e4b076ac5ff20569/t/54c1ddfae4b03be870fcb9ab/1421991420775/" height="245" width="400" /></a>
<br />
Projects can fail for a number of reasons, but at the root of most failures is a failure to gather <b>correct and consistent requirements</b>. We've all laughed at some variant of the above diagram, but these issues are all because:<br />
<ul style="text-align: left;">
<li>We fail to capture correct and consistent requirements</li>
<li>We play "broken telephone" when we are communicating requirements</li>
</ul>
<div>
Let's take a concrete example. Suppose we have an orienteering challenge where you need to go from the <b>start</b> point below to the <b>finish</b> point, this is the <b>actual </b>requirement. </div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiesxhe86lMRx0IOPd_PbEQUJ90YYsuypKRd8S92SWnnAKZ3WRG7xyJnOTxon0ZZKR8GtyLKZ4x4Io799wxbSADp0KMXY9sxCCGFhmieUwnf9il9STESv87MFsd6lQ8NBtE7sxPWqMftdY/s1600/Orienteering+challenge%2C+map+1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="321" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiesxhe86lMRx0IOPd_PbEQUJ90YYsuypKRd8S92SWnnAKZ3WRG7xyJnOTxon0ZZKR8GtyLKZ4x4Io799wxbSADp0KMXY9sxCCGFhmieUwnf9il9STESv87MFsd6lQ8NBtE7sxPWqMftdY/s400/Orienteering+challenge%2C+map+1.jpg" width="400" /></a></div>
<div style="text-align: center;">
<span style="color: yellow; font-size: large;"><br /></span></div>
<div style="text-align: center;">
<span style="color: yellow; font-size: large;">But, there is a gap between what the actual requirements are and what is actually written down.</span></div>
<div>
<br /></div>
<div>
<b><span style="font-size: x-large;">Good Requirements</span></b><br />
<br />
As long as the written requirements don't diverge too much from the actual requirements, you will have time to adjust the requirements during project execution and still get to the <b>finish </b>point. </div>
<div>
<br /></div>
<div>
So as long as the initial written requirements are in the<span style="color: #444444;"> <span style="background-color: lime;">green</span></span> zone, you can still complete the project on time because the requirements point you in the correct direction.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEND8CEaCgvACL8urEQQ36zwUciyaGwftjMTq6eivoolESCmIb8bCYokOUAwhUtEx0HBfnm88IsQisZa8lsm4Cl5NN4dH3TUDNYIooWy2acqwz_OPlpSlC8Ff9nYuN_R1BmmFNbZ8DYk8/s1600/Orienteering+challenge%2C+map+2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="322" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEND8CEaCgvACL8urEQQ36zwUciyaGwftjMTq6eivoolESCmIb8bCYokOUAwhUtEx0HBfnm88IsQisZa8lsm4Cl5NN4dH3TUDNYIooWy2acqwz_OPlpSlC8Ff9nYuN_R1BmmFNbZ8DYk8/s400/Orienteering+challenge%2C+map+2.jpg" width="400" /></a></div>
<div>
<br /></div>
<div>
<br />
<span style="font-size: x-large; font-weight: bold;">Mediocre Requirements</span><br />
<br />
Now suppose one of the following happen:</div>
<div>
<ul style="text-align: left;">
<li>You don't have all the core requirements because insufficient people were consulted</li>
<li>You have conflicting requirements from different sources</li>
</ul>
<div>
When you have less than accurate requirements you will be in trouble. The initial code and architecture of the project will be created based on the quality of the requirements. If those requirements are suspect, then there will be rework as code needs to be adjusted as the scope of the project seems to shift.</div>
</div>
<div>
<br /></div>
<div>
So now you will find yourself in one of the <span style="background-color: yellow;"><span style="color: #444444;">yellow</span> </span>zones below</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_VvncVaLXRDeNz-2nK8q0QroqULZXfKQQctUvkZKMuPdvvwSf6vjIE0BAZjnPSC7m8AgXmAcm3RTDJQkTeG0QeH9c0PLBOFqIhFPHGith9h6i9VKP_zQU5Y4kl7bs2dL2SkZaEmDggCQ/s1600/Orienteering+challenge%2C+map+3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="322" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_VvncVaLXRDeNz-2nK8q0QroqULZXfKQQctUvkZKMuPdvvwSf6vjIE0BAZjnPSC7m8AgXmAcm3RTDJQkTeG0QeH9c0PLBOFqIhFPHGith9h6i9VKP_zQU5Y4kl7bs2dL2SkZaEmDggCQ/s400/Orienteering+challenge%2C+map+3.jpg" width="400" /></a></div>
<div>
<br /></div>
<div>
Even with the best execution, the project will be challenged. Deadlines will be missed as you attempt to bring the requirements back to what they need to be. This is like trying to change a tire on a car and discovering the jack is missing.</div>
<div>
<br /></div>
<div>
It is important to realize that adjusting poor requirements is not <b>Scope Creep</b>. Fixing incorrect and inconsistent requirements is necessary and it is pointless for a project manager or executive to disallow these changes. It would be worthwhile for project postmortems if the project manager tracked whether a requirement was <b>missing </b>or <b>inconsistent</b>.</div>
<div>
<br /></div>
<div>
Challenged projects are typically declared as successes, but only after massive compromises, burned out resources, damage to reputations, and loss of revenue. When all the damage is taken into account, this is hardly a victory.</div>
<div>
<br /></div>
<div>
<br />
<span style="font-size: x-large; font-weight: bold;">Bad Requirements</span><br />
<br />
The last situation occurs where you only have vague requirements before you start a project. This situation happens where the executives need a project done quickly and over-estimate the teams familiarity with the subject domain.</div>
<div>
<br /></div>
<div>
These projects start with requirements in the <span style="background-color: red; color: white;">red</span> zone below. You don't have a prayer of completing this project and it will turn into a <b><a href="https://en.wikipedia.org/wiki/Death_march_(project_management)" target="_blank">Death March</a> </b>with all of its characteristics<b> (see <a href="http://accelerateddevelopment.blogspot.ca/2013/01/death-march-mathematics.html" target="_blank">Death March Calculus</a>)</b>.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwFs8T9Rs_-nNVNyRoo6sOFrktu0Bl4dUF1TYk5Tg6fR5bB4rloqcs3HUy-r7Qe5HqoHJhu-ivP_4AC1Zg2yT4iVkpiNRI8EKaVDmc2CraVrFD18w2QRzJH1Yq574XS4DrBtblJOD8uwk/s1600/Orienteering+challenge%2C+map+4.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="322" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwFs8T9Rs_-nNVNyRoo6sOFrktu0Bl4dUF1TYk5Tg6fR5bB4rloqcs3HUy-r7Qe5HqoHJhu-ivP_4AC1Zg2yT4iVkpiNRI8EKaVDmc2CraVrFD18w2QRzJH1Yq574XS4DrBtblJOD8uwk/s400/Orienteering+challenge%2C+map+4.jpg" width="400" /></a></div>
<div>
<br /></div>
<div>
Making core course corrections to bad requirements are like trying to change a tire on a car when you are going down the highway at 100 mph. It won't happen.</div>
<div>
<br /></div>
<div>
<span style="font-size: x-large; font-weight: bold;">Conclusion</span><br />
<br />
It is human nature to assume that the sooner you start a project that the sooner you will finish. That assumption is only correct if you have good requirements to point you in the correct direction. Good requirements are consistent and correct and include at a minimum the core requirements for the primary users.<br />
<br />
Starting a project with mediocre or poor requirements is simply a recipe for project failure. Mediocre or poor requirements are incomplete and inconsistent.<br />
<br />
If you have been part of a project failure then you will discover that despite the other factors that went wrong, requirements failure was at the root of it.</div>
<div>
<br /></div>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-48475134125664450022016-08-08T12:20:00.002-07:002017-01-09T08:51:24.265-08:00Specifically, what is complexity?<div dir="ltr" style="text-align: left;" trbidi="on">
People involved in software projects would say that software development is about understanding complexity.<br />
<br />
<span style="color: yellow; font-size: large;">What is complexity?</span><br />
<br />
<span style="color: yellow; font-size: large;">What can we do about it?</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGyJwxDZfFwVLSFwK49Wa-gc4x5cIULSO9EKckIQKn8TDcVir-aPMwZPt-3XxuTJxQZadGGghfLiMRzRam3la_whSBqlEsvvu9dZP7N2QVw9pQCCwciSoj7OeRKwaT8dGx4CEGgVGxrD0/s1600/Complexity.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="114" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGyJwxDZfFwVLSFwK49Wa-gc4x5cIULSO9EKckIQKn8TDcVir-aPMwZPt-3XxuTJxQZadGGghfLiMRzRam3la_whSBqlEsvvu9dZP7N2QVw9pQCCwciSoj7OeRKwaT8dGx4CEGgVGxrD0/s200/Complexity.jpg" width="200" /></a></div>
Complexity is easy to define at a high level, but people get vague when pressed for a precise definition. Let's see if we can:<br />
<br />
<ul style="text-align: left;">
<li>quantify the problem</li>
<li>define it</li>
<li>suggest how to address it</li>
</ul>
<br />
<div class="Next">
Assume we need to develop a project of 50,000 lines of code <sup><b>1</b></sup>
, this project would take 5,000 man days to develop (<span style="color: yellow;">scenario <b>A</b></span>) assuming 10
production lines of code per day <sup><b>2</b></sup>. Even if we are generous
and assume 50 production lines of code per day per developer, the project would
still take 1,000 man days to develop.<br />
<br />
Now take that developed code and have a single developer re-enter
it (<span style="color: yellow;">scenario <b>B</b>)</span>. The developer is likely to be able to code at least 1,000 lines of code per day and it would only take
about 50 man days to enter the entire program. <br />
<br />
The difference between <span style="color: yellow;">scenario A </span>and <span style="color: yellow;">scenario B </span>is 950 days to create the <b>same software system</b>. So what are we doing in the other 950 days if it only takes 50 days to write the code?<br />
<br />
<span style="color: yellow; font-size: large;"><b>95% of a project is about solving problems, not writing code</b></span><br />
<br />
In scenario <b>A</b> we don't know which lines of code to write, time is expended in figuring out:<br />
<ul style="text-align: left;">
<li>determining what the actual requirements are</li>
<li>translating the requirements into high level design</li>
<li>designing an architecture sufficient to support the requirements</li>
<li>translating the high level design into programming languages / libraries</li>
<li>discovering where the code defects are</li>
<li>rewriting code for incorrect functionality</li>
</ul>
<div>
While it might seem startling that 95% of our time is spend figuring out which lines of code to write, a little reflection will convince us that this is the case. We mistakenly believe that projects fail because there is not enough time to write the code, but really, the problem is that we don't know what lines of code to write.</div>
<div>
<br /></div>
<span style="color: yellow; font-size: large;"><b>Projects do not fail because their is insufficient time to write code</b></span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://jilo.bg/sites/default/files/styles/original/public/images/2016/02/03/012.jpg?itok=bIfnSCvZ" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://jilo.bg/sites/default/files/styles/original/public/images/2016/02/03/012.jpg?itok=bIfnSCvZ" height="123" width="320" /></a></div>
When you see developers furiously coding at their desks, they are spending most of their time thinking. <br />
<br />
Most developers are unable to sit and plan away from the computer, so when you see them at their keyboards they are primarily thinking. They will write and rewrite sections of code as they think through the problems (see <a href="http://accelerateddevelopment.blogspot.ca/2013/05/not-planning-is-for-losers.html" target="_blank">Not Planning is for Losers</a>).<br />
<div style="text-align: left;">
<span style="font-size: large;"><b><br /></b></span></div>
<div style="text-align: left;">
<span style="font-size: x-large;"><b>
Where does Complexity Come From?</b></span></div>
<div>
Now that we have quantified how much time is spent solving complexity, where does it come from?<br />
<br />
Complexity comes from team resources not understanding how to solve the problems they face. When confronted with a problem the team must think about how to solve it.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://cdn-images-1.medium.com/max/800/1*S1TwhPkV5GVn5fvlCjqndw.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://cdn-images-1.medium.com/max/800/1*S1TwhPkV5GVn5fvlCjqndw.gif" width="200" /></a></div>
Each problem is like figuring out a path in a maze, it takes time to solve it initially. Once you have solved the problem, it is easy to avoid all the dead ends and go straight to a solution. <br />
<br />
<span style="color: yellow; font-size: large;"><b>We spend 95% of our time considering alternatives and hitting dead ends.</b></span><br />
<br />
Complexity is not a issue if enough time has been budgeted in the project for the team to think things through. Complexity is a problem when you need to think through issues and insufficient time is budgeted. <br />
<br />
Projects run late mainly because of two reasons:</div>
<div>
<ol style="text-align: left;">
<li>Insufficient time</li>
<ul>
<li>You did not use formal estimation techniques and underestimate the project</li>
<li>You use formal estimates and executives push for a delivery date independent of the problems to be solved in the project</li>
</ul>
<li>Insufficient requirements</li>
<ul>
<li>You estimated sufficient time for your team's skill level to solve the problems but you did not have all the requirements</li>
</ul>
</ol>
</div>
<div>
<div style="text-align: left;">
<span style="font-size: large;">
Insufficient time</span></div>
<div style="text-align: left;">
It is pretty clear why insufficient time causes projects to fail, but here are some specific statistics. Often executives reject formal estimates and then push for project deadlines independent of the work to be done (see <a href="http://accelerateddevelopment.blogspot.ca/2012/02/why-senior-management-declared.html" target="_blank">Why Senior Management Declared Deadlines lead to Disaster</a>)</div>
</div>
<div>
<span style="font-size: large;"><br /></span></div>
<div>
<span style="font-size: large;"><span style="color: red; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;">Rejection of estimates for business reasons lead to productivity down 15% and quality down 21%</span><span style="color: white; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; line-height: 18.2px;"> </span></span></div>
<div>
<div>
<span style="font-size: large;"><br /></span></div>
<div>
<span style="font-size: large;"><span style="color: red; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;">Excessive schedule pressure leads to productivity down 16% and quality down 23%</span><span style="color: white; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; line-height: 18.2px;"> </span></span></div>
<div>
<b><span style="color: white; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; line-height: 18.2px;"><br /></span></b></div>
<div>
<div style="text-align: left;">
<span style="font-size: large;">
Insufficient Requirements</span></div>
<div style="text-align: left;">
The second situation happens when you underestimate requirement complexity. On a regular basis projects are launched where only a fraction of the requirements are gathered. Once the project starts there is a mad dash to capture the missing requirements, i.e scope creep (see <a href="http://accelerateddevelopment.blogspot.ca/2012/07/shift-happens.html" target="_blank">Shift Happens</a>). </div>
</div>
</div>
<div>
<br /></div>
<div>
Project plans are often based on the initial set of requirements and the project deadline is not adjusted when you discover that there are missing requirements.</div>
<div>
<br /></div>
<div>
<span style="font-size: large;"><span style="color: red; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;">Failure to estimate requirement changes to schedule lead to productivity down 16% and quality down 22%</span><span style="color: white; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; line-height: 18.2px;"> </span></span></div>
<div>
<h2>
</h2>
<div style="text-align: left;">
<b><span style="font-size: x-large;">
Why We Underestimate Requirement Complexity</span></b></div>
<div>
Human beings are wired to underestimate complexity. For example, suppose that a customer says that they want a car, we all know what a car is, correct? Executives often talk in such generalities when they don't understand why the estimates are high.<br />
<br />
Look at the following cars:</div>
<div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3H5l9Znu7HMy3UxXUVY_1IKRf2scI-VJLKTuleuI5AfVczT-cbMweJIKj2Pxfo9J7JA3wzrlAitG1DSs4odL187WykzA1fqzR-ddviTkCPlWV-pZ7K-Pa-eIIGc1QXJwrVxk6ZD0xawU/s1600/Quality%2C+two+car+pictures.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="75" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3H5l9Znu7HMy3UxXUVY_1IKRf2scI-VJLKTuleuI5AfVczT-cbMweJIKj2Pxfo9J7JA3wzrlAitG1DSs4odL187WykzA1fqzR-ddviTkCPlWV-pZ7K-Pa-eIIGc1QXJwrVxk6ZD0xawU/s320/Quality%2C+two+car+pictures.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both;">
Clearly these cars are not the same, and the cost and time required to build them is not the same. Abstractly, we all understand what a car is and we can discuss this in general. But when we start drilling into the details, there are many questions to be answered, such as:</div>
<div class="separator" style="clear: both;">
</div>
<ul>
<li>How fast does the car need to go?</li>
<li>How many people does it need to seat?</li>
<li>What kind of fuel economy do you want?</li>
<li>What safety features are required?</li>
<li>How sophisticated do the controls need to be?</li>
</ul>
<div>
In the rush to get projects started, we skimp on the requirements process and many questions are not answered. But at some point the developers need that information so that they can solve their problems and the requirements need to be gathered. Quite often projects run out of time simply because they never budgeted time to gather enough requirements.<br />
<br />
<br /></div>
<div style="text-align: left;">
<b><span style="font-size: x-large;">Skill and Complexity</span></b></div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEic0TY8saFgQvYCD2uFD_fkjUjLQAbHi0YpNW7LRahS2rJez4lfJMmBICIfJAcp-DbUI-m9B8Ug273QxsrlzkzPEtCW01AlaXHnrDU1tliSNRVVNH5n9w9EGJouI2Oc29P3zYbnxTiKgKI/s1600/maze.gif" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEic0TY8saFgQvYCD2uFD_fkjUjLQAbHi0YpNW7LRahS2rJez4lfJMmBICIfJAcp-DbUI-m9B8Ug273QxsrlzkzPEtCW01AlaXHnrDU1tliSNRVVNH5n9w9EGJouI2Oc29P3zYbnxTiKgKI/s200/maze.gif" width="200" /></a></div>
<div>
There is a clear trade off between the time required to solve a complex problem and the skill level of the team. A problem is complex when you have never seen it before, but once you have solved it, then you always see the solution.</div>
<div>
<br /></div>
<div>
Just like the maze shown here, the first time might take a fair amount of time to figure out the solution. If you have to solve the problem again then you will go directly to the solution without dead ends.</div>
<div>
<br /></div>
<div>
When gathering requirements, the better the analyst understands the domain, the less likely they are to miss requirements or have inconsistent requirements. This eliminates the likelihood of inconsistent requirements and increases the probability that enough requirements are captured to start the project. </div>
<div>
<span style="color: yellow; font-size: large;"><b><br /></b></span></div>
<div>
When developers have experience with the domain then they take much less time to break the requirements into high level designs. When they have experience with the language being used and the libraries they can translate that high level design into a low level design and code much quicker.<br />
<br />
<br />
<b><span style="font-size: x-large;">Solving Complexity</span></b></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL7uaq3HlLXuNwqbqo8wIeDXh0ClLieM4-ozK0Xhaubm9Y7O5SDYcbHU13qAC5xlxXLmvH0NZtNo2hFVTbcsrm16hdq6wMh1AxZ6YtkHP5tuN2YfYMB7icA63lVz25D9mAuDHe8S4S1nA/s1600/Complexity%2C+Skill+vs+Time+tradeoff.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL7uaq3HlLXuNwqbqo8wIeDXh0ClLieM4-ozK0Xhaubm9Y7O5SDYcbHU13qAC5xlxXLmvH0NZtNo2hFVTbcsrm16hdq6wMh1AxZ6YtkHP5tuN2YfYMB7icA63lVz25D9mAuDHe8S4S1nA/s200/Complexity%2C+Skill+vs+Time+tradeoff.png" width="200" /></a></div>
<div>
So successful software projects recognize that complexity amounts to the thinking time required for the team to figure out problems they have not solved before.<br />
<br />
The more experienced a resource, the less time they need to think about the final solution. The less experienced resources need more time to think through problems, especially when they hit dead ends.</div>
<div>
<ul style="text-align: left;">
<li>For the business analysts and product managers</li>
<ul>
<li>This is about understanding the subject matter and making sure to gather enough consistent requirements</li>
</ul>
<li>For the developers </li>
<ul>
<li>This is about understanding the subject matter for high level design, and understanding the language and libraries for implementation</li>
</ul>
<li>For the project managers </li>
<ul>
<li>This is about understanding how capable the team is and making sure that sufficient time is budgeted for them to solve all problems</li>
</ul>
<li>For the IT executives </li>
<ul>
<li>This is about understanding that any given project team needs sufficient time to solve problems and not caving into executive pressure to arbitrarily shorten projects</li>
</ul>
</ul>
</div>
<div>
<h2 style="text-align: left;">
<span style="font-size: x-large;">References</span></h2>
<ul style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;">
<li>Jones, Capers.<a _blank="" href="http://bit.ly/CJ_BestWorstPractices">SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS</a>. 2008.</li>
</ul>
</div>
<br />
<hr align="left" size="1" width="33%" />
<!--[endif]-->
<br />
<sup>1</sup> Lines of code is a
terrible metric and is only used here to illustrate a point about
complexity. Software measurement
should use function points or another relevant metric.</div>
<sup>2</sup> Brooks, Frederick
Phillips. “The Mythic Man Month”, 1995. <a href="https://en.wikipedia.org/wiki/Special:BookSources/0201006502">ISBN 0-201-00650-2</a>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-12768711576284901792016-07-08T15:52:00.000-07:002017-01-09T08:51:24.168-08:00User stories or use cases?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://alistair.cockburn.us/get/3199" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://alistair.cockburn.us/get/3199" height="200" width="169" /></a></div>
<a href="http://alistair.cockburn.us/" target="_blank">Alistair Cockburn</a> says "<a href="http://alistair.cockburn.us/A+user+story+is+to+a+use+case+as+a+gazelle+is+to+a+gazebo">A user story is to a use case as a gazelle is to a gazebo</a>".<br />
<br />
If you are extremely familiar with both techniques then this makes sense. If you are not familiar with both then suffice it to say that you can put a gazelle in a gazebo but not vice versa.<br />
<br />
A user story is of the form <em><strong>As a <type of user>, I want <some goal> so that <some reason></strong> (see <a href="https://www.mountaingoatsoftware.com/agile/user-stories">here</a>). </em><br />
<br />
A use case for <strong>withdraw money</strong> has many more components to it, and a skeleton of such a use case can be found <a href="http://accelerateddevelopment.ca/doc/Use%20case,%20withdraw%20money,%20attributes.doc">here</a>. I develop this skeleton use case in a four part tutorial:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://alluscu.com/images/uploads/whatsnew/atm.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="108" src="https://alluscu.com/images/uploads/whatsnew/atm.jpg" width="200" /></a></div>
<ul class="siteMap">
<li><a href="http://accelerateddevelopment.blogspot.com/2012/03/use-case-tutorial-1-of-3.html">Part 1</a>: Use case as a dialog</li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/03/use-case-tutorial-2-of-3.html">Part 2</a>: What is an actor?</li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/03/use-case-tutorial-3-of-4.html">Part 3</a>: Adding interface details</li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/04/use-case-tutorial-4-of-4.html">Part 4</a>: Adding application context</li>
</ul>
The above user story is only a part of the entire use case. For an ATM, a user story might be <strong><span style="color: yellow;">As a user, I want to withdraw money so that I can have physical cash</span></strong>. This user story is only the summary of the withdraw money use case without the details.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://pbs.twimg.com/media/CPoxuO0UsAA7fzF.jpg:thumb" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://pbs.twimg.com/media/CPoxuO0UsAA7fzF.jpg:thumb" /></a></div>
User stories come from the <a href="https://en.wikipedia.org/wiki/Extreme_programming#Testing_2">Extreme Programming</a> methodology. The assumption was that there will be a high degree of interaction between the developers, and the end customer and that QA will largely be done through <a href="https://en.wikipedia.org/wiki/Test-driven_development">test driven development</a>. It is important to realize that Extreme Programming does not scale.<br />
<br />
Once your development team gets large, i.e. you have 3+ agile teams and your code base gets large enough to warrant a formal testing environment, then you will outgrow user stories as your only method of capturing requirements. <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://static8.bigstockphoto.com/thumbs/4/6/2/small2/2645209.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://static8.bigstockphoto.com/thumbs/4/6/2/small2/2645209.jpg" /></a></div>
<br />
You can still use user stories for new modules
developed with an end customer to take advantage of the light weight and rapid nature of user stories, but at some point those user stories should transition to use cases.<br />
<br />
Unfortunately, there are quite a few ways to build use cases and not all of them are effective. Alistair Cockburn's method (found <a href="http://alistair.cockburn.us/get/2465">here</a>) is an excellent way to capture use cases for more sophisticated systems. There is no doubt that use cases are heavier weight than user stories, but consider this:
<br />
<ul>
<li>Use cases can more easily be turned into test cases by QA</li>
<li>With use cases you more easily prove that you have all the requirements</li>
<li>Use cases annotated with screens and reports can be used to collaborate with remote off site customers</li>
<li>Well written use cases can easily be broken up into a sprint back log</li>
<li>Use cases will work if you are not using Agile development methods<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.chokleong.com/wp-content/uploads/2013/06/plant_growth-300x109.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.chokleong.com/wp-content/uploads/2013/06/plant_growth-300x109.jpg" /></a></div>
</li>
</ul>
So don't forgo the speed and dynamic nature of user stories, just recognize that there are limits to user stories and that you will need to transition to use cases when your project team or application grows.</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0Vancouver, BC, Canada49.2827291 -123.1207375000000249.1169101 -123.44346100000001 49.4485481 -122.79801400000002tag:blogger.com,1999:blog-3605277307868077948.post-76476836765870434682016-06-17T09:55:00.003-07:002017-01-09T08:51:24.329-08:00Ready, Fire, Aim: How most gather requirements<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzdbEfWKXHDkalk0bIVkzxgEYS2waj1zxtdFG4Lu5FMET6fUogWPchPEncUb3LTZYvkt63nMrSUf4lthi7UFeRLhSgailFeOP9xRF_Od5RGvHKrjKIDrbknqwcO5pC7xqSbDZebrsVTpo/s1600/missed_target-300x204.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="136" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzdbEfWKXHDkalk0bIVkzxgEYS2waj1zxtdFG4Lu5FMET6fUogWPchPEncUb3LTZYvkt63nMrSUf4lthi7UFeRLhSgailFeOP9xRF_Od5RGvHKrjKIDrbknqwcO5pC7xqSbDZebrsVTpo/s200/missed_target-300x204.jpg" width="200" /></a></div>
Connecting with your customers and delivering value depends on understanding your customer's requirements and selling the correct product or solution that solves your customer's problems.<br />
<br />
Commonly, the requirements gathering process is done hastily or not at all in the rush to get the sale. After all, <span style="color: yellow;">the faster you can make the sales, the faster the money is in the bank -- correct?</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioGXRgILBiPIGme2hz6LmQ0QELJMTGcWEpYTQBc2xEGa-jH0xAHtu2lKyRcf7w0_6y296lHTmi5kl9Lz2c-dkDNBu3x54flpuJtpLi1a1DPL_1IF55i-jrTF95flnVqM7oF3EGBgi7W0M/s1600/tailoring.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioGXRgILBiPIGme2hz6LmQ0QELJMTGcWEpYTQBc2xEGa-jH0xAHtu2lKyRcf7w0_6y296lHTmi5kl9Lz2c-dkDNBu3x54flpuJtpLi1a1DPL_1IF55i-jrTF95flnVqM7oF3EGBgi7W0M/s200/tailoring.jpg" /></a></div>
The more that product customization is required, the more it is important understand the customer's actual problem. Long lead times to build and implement a solution means will not only lead to difficult implementations but also to a more disappointed customer and a loss of future revenue.<br />
<br />
If you build software, which has long lead times, it is even more important to make sure that what you are building will satisfy the customer's requirements as changing the final software solution will be nearly impossible and very costly.
<br />
<br />
<div class="point">
<span style="color: yellow; font-size: large;">Why do we continually misunderstand and sell the wrong solutions and building the wrong software?</span></div>
<h1>
Human Nature</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCIGcnHhJT-gJlaYEnCoW7Kghuk9ni6Bhmgr06sO_vgef7bR-0oAFTinvCoN7MLN5IPwKOHDvIlaoFoOIUQ2WGqm0_lVJFcqEPE-Xm0-l6nMZ6uQVpSjlltX_M1i_rJ9xi00Z6F66l85Q/s1600/TimePressure.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCIGcnHhJT-gJlaYEnCoW7Kghuk9ni6Bhmgr06sO_vgef7bR-0oAFTinvCoN7MLN5IPwKOHDvIlaoFoOIUQ2WGqm0_lVJFcqEPE-Xm0-l6nMZ6uQVpSjlltX_M1i_rJ9xi00Z6F66l85Q/s1600/TimePressure.png" /></a></div>
Time pressures to make a sale put us under pressure and this stress leads to making quick decisions about whether a product or solution can be sold to a customer. We listen to the customer but interpret everything he says according to the products and solutions that we have.<br />
<br />
Often the customer will use words that seem to match exactly the products we have. But then after the sale once we have to implement we often find that either we deliver a poor solution to the customer or a solution is infeasible and we must refund the customers money.<br />
<br />
However, behind every word that the customer is using there is an implied usage, and understanding that implied usage is where we fail to gather requirements.
For example, suppose the customer says <strong><span style="color: yellow;">I need a car</span></strong>.<br />
<br />
Suppose that you sell used cars:
<br />
<ul>
<li>the customer asked for a car</li>
<li>you sell cars</li>
</ul>
Ergo problem solved!
<br />
<ul>
<li>What if the customer needs an SUV but you don't have any?</li>
<li>What if the customer really needs a truck?</li>
<li>What if the customer needs a car with many modifications?</li>
<li>What if the car the customer needs has never been built?</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://s-media-cache-ak0.pinimg.com/236x/e8/45/22/e84522b223a0538fb35d40094f75c110.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="https://s-media-cache-ak0.pinimg.com/236x/e8/45/22/e84522b223a0538fb35d40094f75c110.jpg" /></a></div>
We hear the word <strong><span style="color: yellow;">car </span></strong>and we think that we know what the customer means. The order-taker sales person will spring into action and sell what he thinks the customer needs. Behind the word <strong><span style="color: yellow;">car</span> </strong>is an implied usage and unless you can ferret out the meaning that the customer has in mind, you are unlikely to sell the correct solution.<br />
<br />
<div class="point">
<span style="color: yellow; font-size: large;">If you don't understand how the customer will to use your solution then you don't understand the problem.</span></div>
<h1>
Comedy of Errors</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/proxy/AVvXsEhdXuwg7fMKQgKWL_fh8AN-64MRYDQ-MtibbEqCFaWNMWVmwMdVfzxaH8KGas9zd4KC3oh19IomZEOHr4dfypMVIYbcHKD9G68wFOW6euzHPsjYuFD7MZ4-JiQeXGF1EEXUS5qTuIc--_W1B0tWDXG577pBrr1imM82uSf5V1mTPeQXHa3nwrn4nYPrFjGI635Wkw=w120-h120" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/proxy/AVvXsEhdXuwg7fMKQgKWL_fh8AN-64MRYDQ-MtibbEqCFaWNMWVmwMdVfzxaH8KGas9zd4KC3oh19IomZEOHr4dfypMVIYbcHKD9G68wFOW6euzHPsjYuFD7MZ4-JiQeXGF1EEXUS5qTuIc--_W1B0tWDXG577pBrr1imM82uSf5V1mTPeQXHa3nwrn4nYPrFjGI635Wkw=w120-h120" /></a></div>
For products that require customization, the sale will get transferred to professional services that will dig deeper into the customer's requirements. At this point you discover that the needs of the customer cannot be met. This leads to sales people putting pressure on professional services and product management to <span style="color: yellow;"><b>find a solution</b></span>, after all, losing the sale is not an option.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://yt3.ggpht.com/--_m11nkPz6M/AAAAAAAAAAI/AAAAAAAAAAA/yAQKt2UYj8g/s88-c-k-no-rj-c0xffffff/photo.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://yt3.ggpht.com/--_m11nkPz6M/AAAAAAAAAAI/AAAAAAAAAAA/yAQKt2UYj8g/s88-c-k-no-rj-c0xffffff/photo.jpg" /></a></div>
Sometimes heroic actions by the product management, professional services, and software development teams lead to a <strong><span style="color: yellow;">successful implementation</span></strong>, but usually not until there has been severe pain at the customer and midnight oil burned in your company. You can eventually be successful but that customer will never buy from you again.
<br />
<br />
<h1>
Consequences</h1>
As <a href="https://en.wikipedia.org/wiki/William_Inge_(priest)"><em>WIlliam Ralph Inge</em></a> said, <strong><span style="color: yellow;">There are no rewards or punishments -- only consequences</span></strong>.
The consequence of selling the wrong solution to a customer is:
<br />
<ul>
<li>Whether you lose the sale or not, the customer loses faith in you</li>
<li>The sales person is perceived as incompetent in the rest of the organization especially by professional services and software devleopment</li>
<li>Your cost of sales and implementation is much higher than expected</li>
<li>Your reputation is damaged</li>
</ul>
<h1>
Conclusion</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://pbs.twimg.com/profile_images/639375269623693312/7ka-EFE9_400x400.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://pbs.twimg.com/profile_images/639375269623693312/7ka-EFE9_400x400.jpg" /></a></div>
Selling the correct solution to the customer requires that you understand the customer's problem before you sell the solution.<br />
<br />
When customization is required, good sales people engage resources that can capture the customer's requirements accurately and assess that you can deliver a solution to the customer.<br />
<br />
Slowing down to understand the customer requirements and how you will solve his problems is the key. By understanding the customer's requirements and producing the correct solutions you become a trusted adviser to the customer.
<br />
<br />
See also<br />
<br />
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.ca/2012/07/shift-happens.html" target="_blank">Shift Happens</a>, effect of scope shift in a software development project.</li>
</ul>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-45686196662349971632015-10-12T13:50:00.004-07:002017-01-09T08:51:24.256-08:00Do Project Managers need Domain Experience?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.security-guard.ca/wp-content/uploads/2015/04/no-experience-needed-200x200.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.security-guard.ca/wp-content/uploads/2015/04/no-experience-needed-200x200.jpg" /></a></div>
Opinions vary on whether a project manager needs to have <b>domain experience</b>. Certainly project managers that do not have domain experience will be the first to say that domain experience is not necessary as long as they have access to excellent subject matter experts.<br />
<br />
I would advocate a more nuanced position; that is, a project manager does not need domain experience <b>IF </b>his subject matter experts understand the risks and dependencies that are inherent to the domain.<br />
<br />
Let's go through a couple of personal projects that I have been involved with where the project manager did not have domain experience.
<br />
<h1>
Telco Project</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://delimiter.com.au/wp-content/uploads/2012/06/fibre.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://delimiter.com.au/wp-content/uploads/2012/06/fibre.jpg" height="132" width="200" /></a></div>
I am currently involved in a project that involves a LAN/WAN/WIFI upgrade of a large customer for a large telecommunications company. The project manager does not have domain expertise in networks and is counting on the subject matter experts to provide him sufficient input to execute the project.<br />
<br />
The subject matter experts are so advanced in their knowledge of networks that they no longer understand what beginners (i.e. the project manager) do not know. They have assumed that when they indicate things to the project manager that he understands what they mean and will take appropriate actions.<br />
<br />
The project manager is continually running into situations where he did not understand the implications of certain risks and dependencies. This has caused a certain amount of rework and delays.<br />
<br />
Fortunately, this is not a project with tremendous amounts of risk or dependencies so the project will be late but will succeed.
<br />
<h1>
Mobile Handset Project</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.1nps.com/wp/wp-content/uploads/2012/10/Way_Systems_MTT1581.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.1nps.com/wp/wp-content/uploads/2012/10/Way_Systems_MTT1581.gif" height="200" width="200" /></a></div>
In the distant past, I was part of a team that was building a mobile POS terminal that worked over cellular (GSM, CDMA). The project manager in this situation did not have domain experience and was counting on the subject matter experts. In this case, the subject matter experts were very good at general design, but not experts in building cellular devices.<br />
<br />
Because the subject matter experts were not specialists, they knew most of the key principles of designing mobile handsets but did not understand all the nuances of handset design. There were several key issues required by practical handset manufacturing that were overlooked by the generalists and ended up creating such a strong cost over-run that the start-up went out of business.<br />
<h1>
Sumary</h1>
In the first project, the subject matter experts were extremely good, however, the project manager failed to understand the implication of some of their statements and this introduced large delays in the project.<br />
<br />
In the second project, the subject matter experts were generalists and did not understand all the risks and dependencies of the project. The project manager (and start-up) were doomed to fail because "you don't know what you don't know".
Both these projects show that a project can be delayed or fail because a project manager does not have domain experience.<br />
<h1>
Conclusion</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.tarind.com/depgraph_small.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.tarind.com/depgraph_small.jpg" height="159" width="320" /></a></div>
So if a project does not have many uncertainties and dependencies then it is extremely likely that the project manager does not require domain experience and can rely to some degree on his subject matter experts.<br />
<br />
However, if the project has complex uncertainties and/or dependencies then a good project manager without domain experience is likely to find himself in a position where the consequences of not understanding the uncertainties and dependencies will either introduce serious rework or torpedo the project.<br />
<br />
<hr />
See also<br />
<br />
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.ca/2014/08/schedule-risk-is-red-herring.html" target="_blank">Schedule Risk is a Red Herring!!!</a></li>
<li><a href="http://accelerateddevelopment.blogspot.ca/2012/08/uncertainty-and-risk-in-software.html" target="_blank">Uncertainty trumps Risk in Software Development</a></li>
</ul>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-55125807655338089102014-12-17T10:37:00.002-08:002016-07-10T15:27:06.748-07:00Not using UML on Projects is Fatal<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/12/UML.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/12/UML.png" /></a></div>
The <strong>Unified Modeling Language</strong> (<a href="http://en.wikipedia.org/wiki/Unified_Modeling_Language" target="_blank" title="UML">UML</a>) was adopted as a standard by the <a href="http://en.wikipedia.org/wiki/Object_Management_Group" target="_blank" title="OMG">OMG</a> in 1997, almost 20 years ago. But despite its longevity, I'm continually surprised at few organizations actually use it.<br />
<br />
<strong>Code</strong> is the ultimate model for software, but it is like the trees of a forest. You can see a couple, but only few people can see the entire forest by just looking at the code. For the rest of us, diagrams are the way to see the forest, and UML is the standard for diagrams.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.greenpeace.org/canada/Global/canada/image/2010/4/teaser/boreal/BOREAL%20FOREST%204.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://www.greenpeace.org/canada/Global/canada/image/2010/4/teaser/boreal/BOREAL%20FOREST%204.jpg" height="117" width="200" /></a></div>
They say, "<em>A picture is worth a thousand words</em>", and this is true for code; even on a large monitor you can only see so many lines of code. Every other engineering discipline has diagrams for complex systems, e.g. design diagrams for airplanes, blueprints for buildings. In fact, the diagrams need to be created and approved BEFORE the airplane or building is created.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.proprofs.com/quiz-school/user_upload/ckeditor/fastdrive.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.proprofs.com/quiz-school/user_upload/ckeditor/fastdrive.jpg" height="136" width="320" /></a></div>
Contrast that with software where UML diagrams are rarely produced, or if they are produced, they are produced as an after thought. The irony is that the people pushing to build the architecture <strong>quickly</strong> say that there is no time to make diagrams, but they are the first people to complain when the architecture sucks. UML is key to planning (see <a href="http://accelerateddevelopment.blogspot.ca/2013/05/not-planning-is-for-losers.html" target="_blank" title="Not planning is for losers">Not planning is for losers</a>)<br />
<br />
I think this happens because developers, like all people, are focused on what they can see and touch right now. It is easier to try to code a GUI interaction or tackle database update problems than it is to work at an abstract level through the interactions that are taking place from GUI to database<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://media-cache-ec0.pinimg.com/216x146/0f/d1/f0/0fd1f0fc265a74dce84eb54d6a88e69e.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://media-cache-ec0.pinimg.com/216x146/0f/d1/f0/0fd1f0fc265a74dce84eb54d6a88e69e.jpg" /></a></div>
Yet this is where all the architecture is. Good architecture makes all the difference in medium and large systems. Architecture is the glue that holds the software components in place and defines communication through the structure. If you don't plan the layers and modules of the system then you will continually be making compromises later on.<br />
<br />
In particular, medium to large projects (>10,000 function points) are at a very high risk of failure if you don't consider the architectural issues. Considering only 3 out of 10 software projects are successful only a fool would skip planning the architecture (see <a href="http://accelerateddevelopment.blogspot.ca/2014/06/failed-you-get-what-you-deserve.html" target="_blank" title="Failed? You get what you deserve!">Failed? You get what you deserve!</a>)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.allix.net/images/databasedevelopment.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://www.allix.net/images/databasedevelopment.jpg" /></a></div>
Good diagrams, in particular UML, allow you to abstract away all the low level details of an implementation and let you focus on planning the architecture. This higher level planning leads to better architecture and therefore better extensibility and maintainability of software.<br />
<br />
If you are a good coder then you will make a quantum leap in your ability to tackle large problems by being able to work through abstractions at a higher level. How often do we find ourselves unable to implement simple features simply because the architecture doesn't support it?<br />
<br />
Well the architecture doesn't support it because we spend very little time developing the blueprint for the architecture of the system.<br />
<br />
UML diagrams need to be produced at two levels:<br />
<ul>
<li>the analysis or 'what' level</li>
<li>the design or 'how' level</li>
</ul>
Analysis UML diagrams (class, sequence, collaboration) should be produced early in the project and support all the requirements. Ideally you use a requirements methodology that allows you to trace easily from the requirements onto the diagrams.<br />
<br />
Analysis diagrams do not have implementation classes on them, i.e. no vendor specific classes. The goal is to identify how the high level concepts (user, warehouse, product, etc) relate to each other.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://blog.klocwork.com/wp-content/uploads/2010/09/fda_tool_validation1.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://blog.klocwork.com/wp-content/uploads/2010/09/fda_tool_validation1.jpg" height="199" width="200" /></a></div>
These analysis level UML diagrams will help you to identify gaps in the requirements before moving to design. This way you can send your BAs and product managers back to collect missing requirements when you identify missing elements before you get too far down the road.<br />
<br />
Once the analysis diagrams validate that the requirements are relatively complete and consistent, then you can create design diagrams with the implementation classes. In general the analysis diagrams are one to many to the design diagrams.<br />
<br />
Since you have validated the architecture at the analysis level, you can now do the design level without worrying about compromising the architectural integrity. Once the design level is complete you can code without compromising the design level.<br />
<br />
When well done the analysis UML, design UML, and code are all in sync. Good software is properly planned and executed from the top down. It is mentally tougher to create software this way, but the alternative is continuous patches and never ending bug-fix cycles.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl1TlMasTqbQBn0UxtPD_AH0G5Ob6DcDRTrAuHrGoKZo1i4POSJVDiL8F5ttCd_ruTsGsbn9s5fH5AOqQfZN1LemeVOP1FcqChn7D8pnZO0Qqgt9HXkE5tdqrqu2h1ypnIRUqFF8KF9qI/s1600/7+habits+of+Highly+Effective+People.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl1TlMasTqbQBn0UxtPD_AH0G5Ob6DcDRTrAuHrGoKZo1i4POSJVDiL8F5ttCd_ruTsGsbn9s5fH5AOqQfZN1LemeVOP1FcqChn7D8pnZO0Qqgt9HXkE5tdqrqu2h1ypnIRUqFF8KF9qI/s1600/7+habits+of+Highly+Effective+People.jpg" width="128" /></a></div>
So remember the following example from Covey's <a href="http://en.wikipedia.org/wiki/The_Seven_Habits_of_Highly_Effective_People" target="_blank" title="The Seven Habits of Highly Effective People">The 7 Principles of Highly Effective People</a>:
<br />
<div style="padding-left: 30px;">
<i><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">You enter a clearing where a man is furiously sawing at a large log, but he is not making any progress. You notice that the saw is dull and is unable to cut the wood, so you say, "Hey, if you sharpen the saw then you will saw the log faster". To which the man replies, "I don't have time, I'm too busy sawing the log".</span></i></div>
<div class="point">
<br /></div>
<div class="point" style="text-align: center;">
<span style="color: yellow; font-size: x-large;">Don't be the guy sawing </span><br />
<span style="color: yellow; font-size: x-large;">with a dull saw</span></div>
<br />
UML is the tool to <b>sharpen </b>the saw, it does take time to learn and apply, but you will save yourself much more time and be much more successful.
<br />
<h1>
Bibliography</h1>
<ul>
<li>Covey, Stephen. <a href="http://www.amazon.ca/The-Habits-Highly-Effective-People/dp/0743269519" target="_blank" title="The 7 Habits of Highly Effective People">The 7 Habits of Highly Effective People</a></li>
<li>OMG, <a href="http://www.uml.org/">Unified Modeling Language™ (UML®) Resource Page</a></li>
</ul>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-65216509605975930082014-11-04T13:17:00.003-08:002017-01-09T08:51:24.310-08:00Pair Programming for Team Building<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.commitstrip.com/wp-content/uploads/2012/08/Strips-Pair-coding-550-finalenglish.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.commitstrip.com/wp-content/uploads/2012/08/Strips-Pair-coding-550-finalenglish.jpg" height="216" width="320" /></a></div>
<strong>Extreme programming</strong> (XP) introduced most people to pair programming.<br />
<br />
The theory was that the sooner that code was <b>reviewed</b>, the more <b>effective </b>the review -- so how much more effective can you be if you do that review right away?
<br />
<br />
<div class="positiveEmphasis">
<span style="color: lime; font-size: large;"><b>Pair programming increases productivity by 3% and quality by 5%</b></span></div>
<div class="positiveEmphasis">
<br /></div>
The reason it isn't a better practice is that two people are being used to produce a single result and so it is <strong>not very efficient.</strong> For more information about the marginal productivity see Capers Jones<sup>1</sup>.<br />
<br />
However, as a <b>team building</b> tool, pair programming can be extremely effective used in specific situations where high productivity is maintained:
<br />
<ul>
<li>Training new team members in coding conventions</li>
<li>Sharing individual productivity techniques</li>
<li>Working through complex sections of code</li>
</ul>
<div>
<br /></div>
<h2 style="text-align: left;">
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: x-large;">
New Team Members</span></h2>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoqDIqEgDcPaMljHWO9NkPuBSXb2yCa52rcTsDEbct7Sp2I0GcgSUjpUVljtu-mhLVqtdJbZNgCCrnCFwjdzUChHAfcNigql6-P65W4TrwHDT_DQ7egUWrzAYRH763-SEIaHSrsT8DAsis/s1600/man_walking_dog2.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoqDIqEgDcPaMljHWO9NkPuBSXb2yCa52rcTsDEbct7Sp2I0GcgSUjpUVljtu-mhLVqtdJbZNgCCrnCFwjdzUChHAfcNigql6-P65W4TrwHDT_DQ7egUWrzAYRH763-SEIaHSrsT8DAsis/s1600/man_walking_dog2.jpg" /></a></div>
The first issue is self explanatory, pair programming allows you to explain your coding conventions while working on actual projects.<br />
<br />
It also gives you a fairly good glimpse into how that team member will work with the group.<br />
<br />
The key here is that the new member should pair program with <b>different </b>people every day until they have worked with the entire team. This will speed up the integration of new members and get everyone familiar with each other.
<br />
<br />
<h2 style="text-align: left;">
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: x-large;">
Sharing Productivity Practices</span></h2>
<a href="http://static.squarespace.com/static/5245c5f9e4b03b8157c96e96/52548d4fe4b04e8c1613a5d5/52548d5de4b04e8c1613a749/1381272925634/20090831-old-dogs-cartoon.jpg?format=original" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://static.squarespace.com/static/5245c5f9e4b03b8157c96e96/52548d4fe4b04e8c1613a5d5/52548d5de4b04e8c1613a749/1381272925634/20090831-old-dogs-cartoon.jpg?format=original" height="320" width="280" /></a>One of the key benefits of pair programming is that it is an ideal time to share productivity practices.<br />
<br />
Surprisingly, it is not just the less experienced programmers that learn from the more experienced ones. Often, more experienced programmers have picked up habits that they are not even aware of.<br />
<br />
Working with newer programmers can expose you to information on IDEs and new productivity tools that you are not aware of. <br />
<br />
As much as we do keep up, there is continually new stuff coming out and the newer programmers are aware of it. <br />
<br />
In addition, there are sub-optimal habits that we all pick up and no longer notice because we do them all the time.<br />
<br />
<h2 style="text-align: left;">
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: x-large;">
Working Through Complex Code</span></h2>
<a href="http://www.ozone3d.net/public/jegx/201204/ioccc-akari-downsampler.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.ozone3d.net/public/jegx/201204/ioccc-akari-downsampler.jpg" height="320" width="298" /></a>Once you have planned a complex section of code, it can be very helpful to build that section of code as a pair.
For information on planning complex code see:
<br />
<ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/05/not-planning-is-for-losers.html" target="_blank" title="Not Planning is For Losers">Not Planning is for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.ca/2014/04/productive-developers-are-be-smart-and.html" target="_blank" title="Productive Programmers are Smart and Lazy">Productive Programmers are Smart and Lazy </a></li>
</ul>
Planning is 1/2 the work, making sure that you implement that plan can often require two people to make sure that all loose ends (exceptions, boundary cases, etc) are taken care of.<br />
<br />
In particular, these are the sections of code that you want two pairs of eyes on as you are much more likely to recognized a missed alternative or work through weird conditions.
<br />
<br />
<h1>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: x-large;">
Summary</span></h1>
Used appropriately, pair programming can be a great tool for integrating new members into a team, sharing productivity techniques, and reduce defects and improve quality of difficult sections of code.
<br />
<br />
<h1>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: x-large;">
References</span></h1>
<ol>
<li>Jones, Capers and Bonsignour, Olivier. <a href="http://www.amazon.com/s/ref=nb_sb_ss_i_0_26?url=search-alias%3Dstripbooks&field-keywords=the%20economics%20of%20software%20quality&sprefix=the+economics+of+software+%2Cstripbooks%2C205&rh=i%3Astripbooks%2Ck%3Athe%20economics%20of%20software%20quality">The Economics of Software Quality</a>. Addison Wesley. 2011</li>
<li>Jones, Capers. <a href="http://bit.ly/CJ_BestWorstPractices" target="_blank">SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS</a>. 2008.</li>
</ol>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0Vancouver, BC, Canada49.261226 -123.113926849.09541 -123.4366503 49.427042 -122.7912033tag:blogger.com,1999:blog-3605277307868077948.post-19719360155081503422014-10-30T14:04:00.000-07:002016-06-11T06:50:42.471-07:00Team Conflict is for Losers<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/01/Loser-small.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/01/Loser-small.png" /></a></div>
It is a guarantee that you don't like someone on your development team and they have behaviors or habits that you might find objectionable:
<br />
<ul>
<li><strong>Mashable</strong> talks about <a href="http://mashable.com/2014/08/01/annoying-coworkers/" target="_blank" title="45 Most Annoying Office Habits">45 most annoying office habits</a></li>
<li><strong><span style="background-color: white; color: #483c32;">[the nest] </span></strong> talks about <a href="http://ideas.thenest.com/health/mind-and-body/slideshows/10-annoying-work-habits.aspx" target="_blank" title="10 Annoying Work Habits That Can Get You Fired">10 Annoying Work Habits That Can Get You Fired</a>. </li>
</ul>
But as irritating as you find your co-workers, odds are:
<br />
<br />
<div class="point">
<span style="color: yellow; font-size: large;">You do something that they find annoying...</span><br />
<br /></div>
Annoyances and poor communication can lead to conflicts that range from avoidance to all out war where people get drawn into taking sides. But consider the cost of team conflict :
<br />
<br />
<table border="1">
<tbody>
<tr bgcolor="yellow">
<th><strong><span style="color: black;">Issue</span></strong></th>
<th><strong><span style="color: black;">Productivity</span></strong></th>
<th><strong><span style="color: black;">Software Quality</span></strong></th>
</tr>
<tr>
<td>Internal team conflict</td>
<td style="text-align: center;"><span style="color: red;">-10%</span></td>
<td style="text-align: center;"><span style="color: red;">-15%</span></td>
</tr>
<tr>
<td>Management conflict</td>
<td style="text-align: center;"><span style="color: red;">-14%</span></td>
<td style="text-align: center;"><span style="color: red;">-19%</span></td>
</tr>
</tbody>
</table>
<br />
The table above is only showing the <strong>average</strong> result of conflict, some of us have been in situations that get much, much worse.<br />
<br />
Software development is not a <strong>popularity contest</strong>, you don't have to like everyone that you work with. However, if you allow your feelings of annoyance escalate into conflict then there is a real cost to your project and ultimately in your stress levels.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/10/Disagree-Defend-Destroy.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/10/Disagree-Defend-Destroy.png" height="200" width="188" /></a></div>
All conflicts start with disagreements. The <strong>Communications Catalyst</strong><sup>2</sup> talks about the following cycle:<br />
<ul>
<li>Disagree</li>
<li>Defend</li>
<li>Destroy</li>
</ul>
When you <strong>disagree</strong> with your coworkers then they don't feel listened to. They will then <strong>defend</strong> their position by digging in their heels, then you will dig in your heels and the road to <strong>destruction</strong> starts. If there are any annoying habits present then the conflict will escalate quickly.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://pinnaclefresh.com.au/wp-content/uploads/2011/09/key_personel_header.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://pinnaclefresh.com.au/wp-content/uploads/2011/09/key_personel_header.jpg" height="84" width="320" /></a></div>
If things get out of hand then people start taking sides and productivity takes a major hit. In the worst conflicts this leads to <strong>loss of key personnel</strong>, which has been measured to be:
<br />
<br />
<div class="negativeEmphasis" style="text-align: center;">
<span style="color: red; font-size: large;"><b>Loss of key personnel, productivity -16%, quality -22%</b></span><br />
<br /></div>
Losing key personnel who have comprehensive knowledge of business rules and organizational practices tied up in their heads often causes projects to face fault and come to a stand still.
You may feel justified in starting a conflict or escalating one, however, as clever as you think you are, <strong>conflict hurts everyone</strong> -- yourself included. Just remember:
<br />
<br />
<div class="point">
<b><span style="color: yellow; font-size: large;">It is virtually impossible to start/escalate a conflict that doesn't boomerang back and bite you in the @ss!</span></b></div>
<h1>
4 Ways to Avoid or Reduce Conflicts</h1>
Things to consider to avoid conflict:
<br />
<ul>
<li><span style="color: yellow;"><strong>Don't disagree first, signal that the other person has been heard</strong></span>
<ul>
<li>You will rarely agree with everything that someone else says, but start by agreeing with the part that you do agree with.<sup>1</sup> This will at least signal that you have heard them and reduce their anxiety that you are not listening to them.</li>
<li>Even mechanically echoing everything that they just said is a way to signal that you heard what was said.</li>
<li>Once this is done, then talk about what you don't agree with.</li>
</ul>
</li>
<li><span style="color: yellow;"><strong>Don't interrupt people.</strong></span>
<ul>
<li>When you are excited and thoughts are springing to mind then you may be tempted to do all the talking and stop listening; get this under control, take a breath, and let others talk.</li>
<li>People generally consider it rude when you interrupt and will assume arrogance on your part. If you are not trying to be arrogant and someone tells you this then wake up -- you need to listen.</li>
</ul>
</li>
<li><span style="color: yellow;"><strong>Don't be frustrated when people don't understand you</strong></span>
<ul>
<li>If you really know something that others don't then simply restating your point of view will not improve their understanding.</li>
<li>If your friend is lost in a new shopping mall then describing your location will not be helpful in helping him find you. You need to find out where he is and walk him through the steps of getting to your location.</li>
<li>Be open to the idea that there might be something that you are not seeing. With additional information you might revise your point of view.</li>
</ul>
</li>
<li><span style="color: yellow;"><strong>Don't automatically assume that someone is insulting you</strong></span>
<ul>
<li>In virtually every case where someone feels insulted this is a knee-jerk reaction to a misunderstanding where no insult was intended.</li>
<li>Jumping to conclusions is not good under any circumstance, but is lethal in social interactions.</li>
</ul>
</li>
</ul>
Managers should be on the lookout for the signs of conflict and clear them up while they are still small. Most conflicts arise from simple misunderstandings.
You will notice that most organizations will promote people based on their ability to work with others and resolve conflicts over competence.
<br />
<br />
<div class="point">
<span style="color: yellow; font-size: large;">Learning how to resolve conflicts is likely your ticket to an overdue promotion...</span></div>
</div>
<h1>
Other articles in the "Loser" series</h1>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr>
<td style="text-align: center;"><a href="http://accelerateddevelopment.ca/blog_images/KillingSacredCows.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://accelerateddevelopment.ca/blog_images/KillingSacredCows.png" height="115" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Moo?</td></tr>
</tbody></table>
<br />
Want to see more sacred cows get tipped? Check out</div>
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/comments-are-for-losers.html" target="_blank">Comments are for Losers</a>
</li>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/04/defects-are-for-losers.html" target="_blank">Defects are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/07/debuggers-are-for-losers.html" target="_blank">Debuggers are for Losers</a>
</li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/effectiveness-first-efficiency-second.html" target="">Efficiency is for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/01/developers-are-ones-who-inject-defects.html" target="_blank">Testing departments are for Losers</a></li>
</ul>
</div>
</div>
<i>Make no mistake, I am the biggest "Loser" of them all. I believe that I have made every mistake in the book at least once :-)</i><br />
<h1>
References</h1>
<ol>
<li>Carnegie, Dale. <a href="http://www.amazon.ca/How-Win-Friends-Influence-People/dp/0671027034/ref=sr_1_1?s=books&ie=UTF8&qid=1414529665&sr=1-1&keywords=how+to+win+friends+and+influence+people" target="_blank" title="How to Win Friends and Influence People">How to Win Friends and Influence People</a>. 1998.</li>
<li>Connolly, Mickey and Rianoshek, Richard. <a href="http://www.amazon.ca/The-Communication-Catalyst-Mickey-Connolly/dp/0793149045" style="font-style: normal;" target="_blank" title="The Communication Catalyst">The Communication Catalyst</a>, 2002.</li>
<li>Jones, Capers and Bonsignour, Olivier. <a href="http://www.amazon.com/s/ref=nb_sb_ss_i_0_26?url=search-alias%3Dstripbooks&field-keywords=the%20economics%20of%20software%20quality&sprefix=the+economics+of+software+%2Cstripbooks%2C205&rh=i%3Astripbooks%2Ck%3Athe%20economics%20of%20software%20quality">The Economics of Software Quality</a>. Addison Wesley. 2011</li>
<li>Kahneman, Daniel. <a href="http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555" target="_blank" title="Thinking, Fast and Slow">Thinking Fast and Slow</a>. 2011</li>
</ol>
<h1>
Side Note</h1>
My best friend also works in the tech sector, and despite being friends for almost 25 years we have very few beliefs or habits in common. There are subjects that we agree on, but then we don't agree on how they should be handled.<br />
<br />
Even though we are very different people this has never stood in the way of us being able to do things together. If you look around you will see radically different people that manage to cooperate and even thrive.<br />
<br />
The key to all working relationships especially when the other person is very different from you is <strong>respect</strong>.
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-61872949360189221162014-08-22T15:51:00.003-07:002017-01-09T08:51:24.292-08:00Infeasible Projects: Executive Ignorance or IT Impotence?<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/DohDoh2.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="DohDoh2" class="alignright size-full wp-image-1056" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/DohDoh2.png" height="158" width="150" /></a><strong><span style="color: yellow;">Infeasible software</span></strong> projects are launched all the time and teams are continually caught up in them, but what is the real source of the problem?<br />
<br />
There are 2 year actual projects for which the executives set a 6 month deadline.<br />
<br />
The project is guaranteed to fail but is this due to <strong><span style="color: yellow;">executive ignorance</span></strong> or <strong><span style="color: yellow;">IT impotence</span></strong>?
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/InfeasibleTimeline.png"><img alt="InfeasibleTimeline" class="aligncenter size-full wp-image-1053" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/InfeasibleTimeline.png" width="550" /></a><br />
<br />
There is no<span style="color: yellow;"> <strong>schedule risk</strong> </span>in an infeasible project because the deadline will be missed. Schedule risk only exists in the presence of uncertainty (see <a href="http://accelerateddevelopment.blogspot.com/2014/08/schedule-risk-is-red-herring.html" style="color: #1155cc;" target="_blank">Schedule Risk is a Red Herring!!!</a>)<br />
<br />
As you might expect, all executives and IT manager share responsibility for infeasible projects that turn into death marches. Learn about the nasty side effects <a href="http://accelerateddevelopment.blogspot.ca/2013/01/death-march-mathematics.html" target="_blank" title="Death March Calculus">Death March Calculus</a>.
The primary causes for infeasible projects are:
<br />
<ul>
<li>Rejection of formal estimates</li>
<li>No estimation or improper estimation methods are used</li>
</ul>
<div>
<br /></div>
<h1>
Rejecting Formal Estimates</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/Infeasible.jpeg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/Infeasible.jpeg" /></a></div>
This situation occurs frequently; an example would be the <strong><span style="color: yellow;">Denver Baggage Handling System</span></strong> (see <a href="http://calleam.com/WTPF/wp-content/uploads/articles/DIABaggage.pdf">Case Study</a>).<br />
<br />
The project was automatically estimated (correctly) to take 2 years; however, executives declared that IT would only have 1 year to deliver.<br />
<br />
Of course, they failed<sup>1</sup>.<br />
<br />
The deadline was <span style="color: yellow;"><strong>rejected</strong> </span>by executives because it did not fit their desires. They could not have enjoyed the subsequent software disaster and bad press.
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.istockimg.com/file_thumbview_approve/27275060/3/stock-photo-27275060-blindfolded-executive.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://i.istockimg.com/file_thumbview_approve/27275060/3/stock-photo-27275060-blindfolded-executive.jpg" height="100" /></a></div>
<div align="center" style="text-align: left;">
When executives<strong> <span style="color: yellow;">ignore formal estimates</span></strong> they get what they deserve. Formal estimates are ignored because executives believe through sheer force of will that they can set deadlines.</div>
<div align="center" style="text-align: left;">
<br /></div>
<div align="center" style="text-align: left;">
If IT managed to get the organization to pay for formal tools for estimating then it is not their problem that the executives refuse to go along with it.<br />
<br />
<br /></div>
<h1>
Improper Estimation Methods</h1>
The next situation that occurs frequently is using estimation processes that have<strong> <span style="color: yellow;">low validity</span></strong>. Estimation has been extensively studied and documented by <a href="http://en.wikipedia.org/wiki/Tom_DeMarco" target="_blank" title="Tom DeMarco">Tom DeMarco</a>, <a href="http://en.wikipedia.org/wiki/Capers_Jones" target="_blank" title="Capers Jones">Capers Jones</a>, <a href="https://www.google.ca/search?q=edward+yourdon&oq=edward+yourdon&aqs=chrome..69i57j0l5.2960j0j4&sourceid=chrome&es_sm=122&ie=UTF-8" target="_blank" title="Edward Yourdon">Ed Yourdon</a>, and others.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/IceBerg.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/IceBerg.png" /></a></div>
Improper estimation methods will <span style="color: yellow;"><strong>underestimate</strong> </span>a software project every time. Fast estimates will be based on what you can think of, unfortunately, software is not tangible and so what you are aware of is like the tip of an iceberg.<br />
<br />
None of this prevents executives demanding fast estimates from development. Even worse, development managers will <strong><span style="color: yellow;">cave in</span></strong> to ridiculous demands and actually give fast estimates.<br />
<br />
Poor estimates are guaranteed to lead to infeasible projects (see <a href="http://accelerateddevelopment.blogspot.ca/2013/05/who-needs-formal-measurement.html" target="_blank" title="Who Needs Formal Measurement">Who needs Formal Measurement?</a>)
Poor estimates are delivered by IT managers that:
<br />
<ul>
<li>Can't convince executives to use formal tools</li>
<li>Give in to extreme pressure for fast estimates</li>
</ul>
Infeasible projects that result from poor estimates are a matter of IT impotence.<br />
<br />
<h1>
Conclusion</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/ChildWithIceCream.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/ChildWithIceCream.png" /></a></div>
Both executive ignorance and IT impotence lead to<strong> <span style="color: yellow;">infeasible projects</span> </strong>on a regular basis because of poor estimates and rejecting estimates; so there is no surprise here.<br />
<br />
However, infeasible projects are a failure of executives and IT equally because we are all on the same team. It is not possible for part of the organization to succeed if the other one fails.<br />
<br />
Possibly a greater share of problem is with IT management. After all, whose responsibility is a bad decision -- the guys that know what the issues are or the ones that don't.<br />
<strong><br /></strong>
<strong><span style="color: yellow; font-size: large;">If a child wants ice cream before they eat dinner then whose fault is it if you cave in and give them the ice cream?</span></strong><br />
<br />
Unfortunately, even after 60 years of developing software projects, IT managers are either as ignorant as the executives or simply have no intestinal fortitude.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/IntestinalFortitude.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/IntestinalFortitude.png" height="200" width="145" /></a></div>
Even when IT managers convince executives of the importance of estimating tools, the estimates are routinely discarded because they do not meet executive expectations.
<br />
<br />
<div align="center">
<span style="color: lime; font-size: large;"><b>Rejection of automated estimates: productivity -16%, quality -22%</b></span></div>
<br />
Until we can get a generation of IT managers that are prepared to educate executives on the necessity of proper estimation and be stubborn about holding to those estimates, we are likely to continue to have an estimated <a href="http://www.zdnet.com/blog/projectfailures/worldwide-cost-of-it-failure-revisited-3-trillion/15424" target="_blank" title="Worldwide cost of IT failure (revisited): $3 trillion">$3 trillion in failures of software projects</a> every year.
<br />
<br />
<hr />
<h1>
End Notes</h1>
<sup>1</sup>For inquiring minds, good automated estimation systems have been shown to be within 5% of time and cost on a regular basis. Contact me for additional information.
<br />
<br />
<h1>
References</h1>
<ul>
<li>Jones, Capers. <a href="http://bit.ly/CJ_BestWorstPractices" target="_blank">SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.</a></li>
<li>Jones, Capers. <a href="http://www.amazon.ca/Economics-Software-Quality-Capers-Jones/dp/0132582201" target="_blank">The Economics of Software Quality</a>. 2011</li>
<li>Kahneman, Daniel. <a href="http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555" target="_blank" title="Thinking, Fast and Slow">Thinking, Fast and Slow</a>. 2011</li>
</ul>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-13885378997700432742014-08-12T10:33:00.004-07:002017-01-09T08:51:24.173-08:00Schedule Risk is a Red Herring!!!<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://dontpatentit.co.uk/blog/wp-content/uploads/red-herring.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://dontpatentit.co.uk/blog/wp-content/uploads/red-herring.jpg" /></a></div>
We often hear the term <span style="color: yellow;"><strong>schedule risk</strong></span>, however, it is generally a <a href="http://en.wikipedia.org/wiki/Red_herring" target="_blank" title="Red Herring">Red Herring</a>. Stating that the schedule might stretch is about as useful as saying that eating can cause you to gain weight.
<br />
<br />
<div class="smallPoint">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">You may be correct but it gives you no leverage to solve the problem</span></div>
<div class="smallPoint">
<br /></div>
Schedules slip as a result of a problem, if you want to solve the problem then you must identify the<span style="color: yellow;"><strong> root cause</strong></span>. Any problem will result in a task taking longer than expected and potentially affecting the schedule.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/TwoSidesSameCoin1.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/TwoSidesSameCoin1.png" /></a></div>
Risk and uncertainty are two sides of the same coin. Without uncertainty there is no risk.
<br />
<br />
<div class="smallPoint">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">No Uncertainty = No Risk</span></div>
<br />
A risk is a contingent liability; a risk is a future event that is uncertain that has consequences.
The key words are <span style="color: yellow;"><strong>future</strong> </span>and <span style="color: yellow;"><strong>uncertain</strong></span>.
<br />
<div class="smallPoint">
<br /></div>
<div class="smallPoint">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">If 6 months remain and the deadline is in 2 months then there is no schedule risk because there is no uncertainty.</span></div>
<br />
6 months late means that the earliest that the <span style="color: yellow;"><strong>critical path</strong></span> items can finish is in 6 months. Just because the project has not hit the deadline and senior staff doesn't understand the project is late does not qualify the team to talk as if the outcome is uncertain.
<br />
<br />
<div class="smallPoint">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">It is disingenuous and cowardly to suggest to senior staff that a deadline is possible when you know that it is not.</span></div>
<div class="smallPoint">
<br /></div>
When the team knows that they are late, they often talk about tasks as being risky simply because they hope that <strong><span style="color: yellow;">miracles</span> </strong>can happen<sup>1</sup>.
<br />
<br />
<div class="point" style="text-align: center;">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: x-large;">Hope is not a strategy</span></div>
<div class="point">
<br /></div>
In fact, Kahneman points out all of us are wired to bet (pray?) on unlikely outcomes when faced with certain losses, i.e. <strong><span style="color: yellow;">we double down when faced with a loss</span></strong>. Team members know about the negative consequences of failure and make projects seem possible simply because they want to delay the pain. Even worse, as the situation gets more desperate people will take bigger and bigger risks.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/IntestinalFortitude.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/08/IntestinalFortitude.png" /></a></div>
Using the term schedule risk when a project is not feasible essentially robs the managers of making a course correction until the point where very little can be done.<br />
<br />
At a minimum, money can be saved by winding the project down. Few people have the <strong><span style="color: yellow;">intestinal fortitude</span></strong> to speak out when they know that a project is late. Unfortunately, cowardice is very common.<br />
<div class="smallPoint">
<br /></div>
<div class="smallPoint">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">If you take a paycheck then you have an obligation to your organization to tell them when a project is late.</span></div>
<br />
So it makes no sense to talk about schedule risk when:
<br />
<ul>
<li>The project is late and you know it</li>
<li>The project is not late but you see schedule items slipping</li>
</ul>
In the latter case you are much better to talk about why things are slipping rather than using the term schedule risk. By talking about the root cause of the slippage, especially early in a project, can lead to you either solving the problem or adjusting the project deadline. Either way, you will have a greater chance of ending up with a feasible project.
<br />
<br />
<h1>
Related Articles</h1>
<ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/05/why-management-declared-deadlines-lead.html" target="_blank" title="Why Management Declared Deadlines Lead to Disaster">Why Management Declared Deadlines Lead to Disaster</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2014/01/no-business-case-project-failure.html" target="_blank" title="No Business Case = Project Failure">No Business Case == Project Failure</a></li>
</ul>
<h1>
References</h1>
<ul>
<li>Jones, Capers. <a href="http://bit.ly/CJ_BestWorstPractices" target="_blank">SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.</a></li>
<li>Jones, Capers. <a href="http://www.amazon.ca/Economics-Software-Quality-Capers-Jones/dp/0132582201" target="_blank">The Economics of Software Quality</a>. 2011</li>
<li>Kahneman, Daniel. <a href="http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555" target="_blank" title="Thinking, Fast and Slow">Thinking, Fast and Slow</a>. 2011</li>
</ul>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-4763712043128931912014-07-12T18:33:00.001-07:002017-01-09T08:51:24.260-08:00User Stories are Rarely Appropriate<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://withfriendship.com/images/d/18667/extreme-programming.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://withfriendship.com/images/d/18667/extreme-programming.gif" height="198" width="200" /></a></div>
All tools are useful when used appropriately, and <b><span style="color: yellow;">User Stories</span></b> are no different.<br />
<br />
User stories are <span style="color: yellow;"><strong>fantastic</strong></span> when used in small teams on small projects where the team is co-located and has easy access to customers.<br />
<br />
User stories can quickly fall apart under any of the following situations:
<br />
<ul style="text-align: left;">
<li>the team or project is not small</li>
<li>the team is not in a single location</li>
<li>customers are hard to access</li>
<li>project end date must be relatively fixed</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiueNMMy-N0o5R61yqxVDs8V8GMphRn2vIN3YdE2jrA_U7YLyM97CfFZ7TR1XdrYMJZtzTwgKKGANpLIvCYgaemI6kc1rJYSbel4t0S0y5PltldMVcL3-h466n2LiqZfw_b_cmx9d-Ou40/s1600/AgileManifestoIndividuals.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiueNMMy-N0o5R61yqxVDs8V8GMphRn2vIN3YdE2jrA_U7YLyM97CfFZ7TR1XdrYMJZtzTwgKKGANpLIvCYgaemI6kc1rJYSbel4t0S0y5PltldMVcL3-h466n2LiqZfw_b_cmx9d-Ou40/s1600/AgileManifestoIndividuals.png" /></a></div>
User stories were introduced as a core part of <a href="http://en.wikipedia.org/wiki/Extreme_Programming" target="_blank">Extreme Programming</a> (XP). Extreme Programming assumes you have small co-located teams; if you relax (or abandon) any of these constraints and you will probably end up with a process out of control. <br />
<br />
XP, and hence user stories, works in high intensity environments where there are strong feedback loops inside the team and with customers:<br />
<ul style="text-align: left;">
<li><b and="" b="" individuals="" interactions=""><span style="color: yellow;">Individuals and Interactions</span> </b><span and="" b="" individuals="" interactions="">over </span><b and="" b="" individuals="" interactions="">Processes and Tools</b></li>
<li><b><span style="color: yellow;">Customer Collaboration</span></b> over Contract Negotiation</li>
</ul>
<br />
<span style="color: yellow; font-family: 'Trebuchet MS', sans-serif; font-size: large;">User stories need intense intra-team / customer communication to succeed</span><br />
<br />
<a href="http://www.toshiba.com/images/showcase/feature-icons/lightweight-feather.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.toshiba.com/images/showcase/feature-icons/lightweight-feather.png" /></a>User stories are a <strong><span style="color: yellow;">light-weight methodology</span></strong> that facilitates intense interactions between customers and developers and put the emphasis on the creation of code, not documentation. Their simplicity makes it easy for customers to help write them, but they must be complemented with timely interactions so that issues can be clarified.<br />
<br />
Large teams <b><span style="color: yellow;">dilute interactions</span> </b>between developers; infrequent communication leads to a lack of team synchronization. Most organizations break larger teams into smaller groups where communication is primarily via email or managers -- this kills communication and interaction.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://media-cache-ec0.pinimg.com/236x/d1/c7/d9/d1c7d96cfee20ebc131ece1d7862cbdc.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://media-cache-ec0.pinimg.com/236x/d1/c7/d9/d1c7d96cfee20ebc131ece1d7862cbdc.jpg" height="200" width="130" /></a></div>
Larger projects have <strong><span style="color: yellow;">non-trivial architectures</span></strong>. Building non-trivial architecture by only looking at the end user requirements is impossible. This is like having all the leaves of a tree and thinking you can quickly determine where the branches and the trunk should go.<br />
<br />
User stories don't work with teams where intense interaction is not possible. Teams distributed over <span style="color: yellow;"><strong>multiple locations or time zones</strong></span> do not allow intense interaction. You are delusional if you think regular conference calls constitute intense interaction; most stand-up calls done via conference degrade into design or defect sessions.<br />
<br />
When emphasis is on the writing of code then it is critical that customers can be accessed in a <strong><span style="color: yellow;">timely fashion</span></strong>. If your customers are indirectly accessible through product managers or account representatives every few days then you will end up with tremendous latency.<br />
<br />
<span style="color: yellow; font-family: 'Trebuchet MS', sans-serif; font-size: large;">Live weekly demos with customers are necessary to flush out misunderstandings quickly and keep you on the same page</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.thestand.org/wp-content/uploads/2011/10/TheCount.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.thestand.org/wp-content/uploads/2011/10/TheCount.jpg" /></a></div>
User stories are virtually impossible to estimate. Often, we use user stories because there is a high degree of <span style="color: yellow;"><strong>requirements uncertainty</strong></span> either because the requirements are unknown or it is difficult to get consistent requirements from customers.<br />
<br />
Since user stories are difficult to estimate, especially since you don't know all the requirements, project end dates are impossible to predict with accuracy.<br />
<br />
To summarize, intense interactions between customers and developers are critical for user stories to be effective because this does several things:
<br />
<ul>
<li>it keeps all the customers and developers on the same page</li>
<li>it flushes out misunderstandings as quickly as possible</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/Diluted-300x83.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/Diluted-300x83.png" height="110" width="400" /></a></div>
<br />
All of the issues listed initially <span style="color: yellow;"><strong>dilute the intensity</strong></span> of communication either between the team members or the developers and customers. Each issue that increases latency of communication will increase misunderstandings and increase the time it takes to find and remove defects.
<br />
<div>
<br />
So if you have any of the following:
<br />
<ul style="text-align: left;">
<li>Large or distributed teams</li>
<li>Project with non-trivial architecture</li>
<li>Difficult access to customers, i.e. high latency</li>
<li>High requirements uncertainty but you need a fixed project end-date</li>
</ul>
<div>
Then user stories are probably not your best choice of requirements methodology. At best you may be able to complement your user stories with <span style="color: yellow;"><strong>storyboards</strong></span>, at worst you may need some light-weight form of <strong><span style="color: yellow;">use case</span></strong>.</div>
<div>
<hr />
<div>
Light-weight use case tutorial:</div>
<ul style="text-align: left;">
<li>(1 of 4) <a href="http://accelerateddevelopment.blogspot.com/2012/03/use-case-tutorial-1-of-3.html" target="_blank">A use case is a dialog</a></li>
<li>(2 of 4) <a href="http://accelerateddevelopment.blogspot.ca/2012/03/use-case-tutorial-2-of-3.html" target="_blank">Use case diagrams (UML)</a></li>
<li>(3 of 4) <a href="http://accelerateddevelopment.blogspot.ca/2012/03/use-case-tutorial-3-of-4.html" target="_blank">Adding screens and reports</a></li>
<li>(4 of 4) <a href="http://accelerateddevelopment.blogspot.ca/2012/04/use-case-tutorial-4-of-4.html" target="_blank">Adding minimal execution context</a></li>
</ul>
</div>
<hr />
Other requirements articles:</div>
<div>
<ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/07/shift-happens.html" target="_blank" title="Shift Happens">Shift Happens</a> (long)</li>
<li><a href="http://accelerateddevelopment.blogspot.ca/2013/10/dont-manage-enhancements-in-bug-tracker.html" target="_blank" title="Don't Manage Enhancements in the Bug Tracker">Don't manage enhancements in the Bug Tracker</a></li>
<li><a href="http://accelerateddevelopment.blogspot.ca/2014/02/when-ba-means-bllt-artist.html" target="_blank" title="When BA means B∪ll$#!t Artist">When BA means B∪ll$#!t Artist</a></li>
</ul>
</div>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-1934491224162936322014-07-08T11:11:00.000-07:002017-01-09T08:51:24.201-08:00Seriously. The Devil Made me do It!<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/good-vs-evil1.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/good-vs-evil1.jpg" height="222" width="320" /></a></div>
Just as eternal as the cosmic struggle between good and evil is the challenge between our two natures. Religion aside, we have two natures, the part of us that:
<br />
<ul>
<li>thinks things through; makes good or ethical decisions a.k.a. <span style="color: green;">our angelic nature</span></li>
<li>reacts immediately; makes quick but often wrong decisions a.k.a. <span style="color: red;">our devil nature</span></li>
</ul>
Guess the powers that be left a bug in our brains so that it emphasizes<span style="color: yellow;"> fast decisions</span> over good / ethical decisions.
<br />
<br />
<div class="point">
Quite often we make <span style="color: yellow;">sub-optimal </span>or ethically ambiguous decisions <span style="color: yellow;">under pressure</span></div>
<br />
You decide...
<br />
<hr />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/SteamingPile.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/SteamingPile.png" /></a></div>
<strong>Situation</strong>: Your manager comes to you and says that something urgent needs to be fixed right away. Turns out the steaming pile of @#$%$ that you inherited from Bob is malfunctioning again.
<br />
<br />
Of course Bob created the mess and then conveniently left the company; in fact, the code is so bad that the work-arounds have work-arounds.<br />
<br />
<span style="color: green;">Bite the bullet, start re-factoring the program when things goes wrong. It will take more time up front, but over time the program will become stable. Start code inspections on the critical sections to proactively reduce defects (see <a href="http://accelerateddevelopment.blogspot.ca/2012/11/every-developer-is-aware-that-code.html" target="_blank">Inspections are not Optional</a>)</span><br />
<br />
<span style="color: red;">Find another fast workaround and defer the problem to the future. Find a good reason why the junior member of the team should inherit this problem.</span>
<br />
<hr />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/MultiplePaths.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/MultiplePaths.png" width="100" /></a></div>
<strong>Situation</strong>: You've got a challenging section of code to write and not much time to write it.<br />
<span style="color: green;"><br /></span>
<span style="color: green;">Get away from the computer, think things through. Get input from your peers, maybe they have seen this problem before. </span><br />
<span style="color: green;"><br /></span>
<span style="color: green;">Then plan the pathways out and write the code once cleanly. Taking time to plan seems counter intuitive, but it will save time. (see <a href="http://accelerateddevelopment.blogspot.com/2013/05/not-planning-is-for-losers.html" target="_blank">Not Planning is for Losers</a>)</span><br />
<span style="color: red;"><br /></span>
<span style="color: red;">Naw, just sit at the keyboard and bang it out already. How difficult can it be?</span><br />
<hr />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/Blame.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/Blame.jpg" width="100" /></a></div>
<strong>Situation</strong>: The project is late and you know that your piece is behind schedule. However, you also know that several other pieces are late as well.<br />
<br />
<span style="color: green;">Admit that you are late and that the project can't finish by the deadline. Give the project manager and senior managers a chance to make a course correction.</span><br />
<br />
<span style="color: red;">Say that you are on schedule but you are not sure that other people (be vague here) will have their pieces ready on time and it could cause you to become late.</span><br />
<span style="color: red;"><br /></span>
<span style="color: yellow;">This situation is also known as Schedule Chicken...</span><br />
<hr />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/Measurement-small.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/07/Measurement-small.png" /></a></div>
<strong>Situation</strong>: You have been asked to estimate how long a critical project will take. You are only been given a short time to come up with the estimate.<br />
<br />
<span style="color: green;">Tell the project manager that getting a proper estimate takes longer than a few hours. Without proper estimates the project is likely to be severely underestimated and this will come back to bite you and the project manager in the @$$. (See <a href="http://accelerateddevelopment.blogspot.ca/2013/05/who-needs-formal-measurement.html" target="_blank">Who needs Formal Measurement?</a>)</span><br />
<span style="color: red;"><br /></span>
<span style="color: red;">Tell the project manager exactly the date that senior management wants the project to be finished by. You know this is what they want to hear, why deal with the problem now? This will become the project manager's problem when the project is late.</span>
<br />
<hr />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9roZUEDCesvYPMhDFcUTVgsiGd0SteRlurLcHWXhTCaUpGiJVHuJs_JD9DVjcLnTcCV-PHtV7XJhEEN2ZwEVRJCfavYD1u3LBDwuao66gUGRBmzEBo019oEjqJxzNOWUEZZu-sPuuwWmG/s1600/Devil-1.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9roZUEDCesvYPMhDFcUTVgsiGd0SteRlurLcHWXhTCaUpGiJVHuJs_JD9DVjcLnTcCV-PHtV7XJhEEN2ZwEVRJCfavYD1u3LBDwuao66gUGRBmzEBo019oEjqJxzNOWUEZZu-sPuuwWmG/s1600/Devil-1.JPG" height="302" width="320" /></a></div>
The statistics show that we often don't listen to our better (angelic?) natures very often.<br />
<br />
So when push comes to shove and you have to make a sub-optimal or less than ethical decision, just remember:
<br />
<blockquote class="point">
<span style="color: yellow; font-family: Trebuchet MS, sans-serif; font-size: large;">The devil made you do it!</span></blockquote>
Run into other common situations? <a href="mailto:dmahal@accelerateddevelopment.ca" target="_blank">email me</a></div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-19207332361312235862014-06-27T15:15:00.000-07:002017-01-09T08:51:24.196-08:00Failed? You get what you deserve!<div dir="ltr" style="text-align: left;" trbidi="on">
Consider this, few projects fail because of unusual or unforeseen problems. If you are trying to go so fast that you don't do your due diligence or decide to skip steps then -- "<b><span style="color: yellow;">You get what you deserve!</span></b>". <br />
<br />
<span style="color: yellow; font-size: large;">Projects succeed because they do not rely on force of personality and luck.</span><br />
<br />
Only 3 of 10 software projects succeed (see <a href="http://accelerateddevelopment.blogspot.ca/2012/05/executives-understanding-your-chances.html" target="_blank" title="Understanding your Chances of having a Successful Software Project">Understanding Your Chances</a>). Success happens when you implement <strong><span style="color: yellow;">best practices</span> </strong>and avoid <strong><span style="color: yellow;">worst practices</span>; </strong>not just talk about them and convince yourself that you are doing them. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/proxy/AVvXsEipgL7C27VYBFrRba4MAH3tY4h90bR7mj42UQVB6DZ2SoH7HZXiTIizwEeT6h_6YrrbTJDZfHxeHRvWEo9nyL2d9a9gy9zz_UZgnr_16tkm2FPIf7FJx1cYc_5lstcJdjO7faOIf2z9oEAUYVoIVljhPnLoY62GQLAQ1YIO8l-NqjCdzHj9_S6hTkcnGOZm-B-E2hQOLOMoMDrO8Td8Fzc2" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/law-unintended-consequences.png" /></a></div>
Therefore 7 out of 10 projects fail, even if you redefine '<b>challenged projects</b>' as political victories; these projects are often severely over time and budget.<br />
<br />
It is estimated that between <a href="http://www.zdnet.com/blog/projectfailures/worldwide-cost-of-it-failure-revisited-3-trillion/15424" target="_blank"><strong>$3 trillion</strong> and <strong>$6 trillion</strong> dollars are wasted every year in IT</a>; by organizations that "<b><span style="color: yellow;">don't know, and don't know that they don't know</span></b>", i.e. what you don't know can definitely hurt you.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/law-unintended-consequences.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><span style="color: black;"></span></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzLPrELDPsl1WqzV83JfmOR0Llcmm20bkppFrsQa6Lm9b0wlzC-WiA90Sw8qiZtEMiyWcxe3gMlilDLFX2Ij73B31VvvQIf4_ZnWdpKalPPn0cXwu-bWMZT0KVV1qRh9ojjbU7w3r2_LA/s1600/RinseAndRepeat.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzLPrELDPsl1WqzV83JfmOR0Llcmm20bkppFrsQa6Lm9b0wlzC-WiA90Sw8qiZtEMiyWcxe3gMlilDLFX2Ij73B31VvvQIf4_ZnWdpKalPPn0cXwu-bWMZT0KVV1qRh9ojjbU7w3r2_LA/s1600/RinseAndRepeat.png" height="150" width="200" /></a></div>
What is amazing is that failures do not prompt the incompetent to learn why they failed. After the <strong><span style="color: yellow;">post-fail finger-pointing ceremony</span></strong>, people just dust themselves off and rinse and repeat.<br />
<br />
<span style="color: yellow; font-size: large;">There is never enough time to do the project correctly, but there is always enough time to do it again.</span><br />
<span style="color: yellow; font-size: large;"><br /></span>
<br />
<h1>
Ingredients of a Successful Project</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/Ingredients.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="color: black;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/Ingredients.png" /></span></a></div>
<div>
<br /></div>
Successful software projects have the following characteristics:<br />
<ul>
<li>Effective capital budgeting</li>
<li>Proper project sizing</li>
<li>Estimate uncertainty</li>
<li>A focus on defect removal</li>
</ul>
<br />
<ul>
</ul>
<h2>
Capital Budgeting</h2>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.buycigarettes.eu/gallery/default/original/28164/RJ_Reynolds_Tobacco_Company.jpg?1360758029" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.buycigarettes.eu/gallery/default/original/28164/RJ_Reynolds_Tobacco_Company.jpg?1360758029" height="180" width="320" /></a></div>
Capital budgeting means having <b>business cases</b> for major projects and allocating capital to the most promising projects; a little due diligence prevents bad projects from starting.<br />
<br />
For example, RJ Reynolds invested $325 million to develop <a href="http://brandfailures.blogspot.ca/2006/11/brand-idea-failures-rj-reynolds.html" target="_blank">smokeless cigarettes</a> when they knew in the initial pilot that the cigarette tasted bad and no one would buy them.<br />
<br />
<h2>
Project Sizing</h2>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhElcViUYDAwqTbDr_wr3of88ukDVmFba33mnskZMpDjws0hK2agMkUazMsYNeaXYawg6SagI3RibMnCcQwMDqxXdXkN2i8hxvsvvnquq4LOcSiyzI-fwk7titJxHtH9yiQLMHK7BRsmJI/s1600/SizeMatters.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhElcViUYDAwqTbDr_wr3of88ukDVmFba33mnskZMpDjws0hK2agMkUazMsYNeaXYawg6SagI3RibMnCcQwMDqxXdXkN2i8hxvsvvnquq4LOcSiyzI-fwk7titJxHtH9yiQLMHK7BRsmJI/s1600/SizeMatters.png" height="320" width="282" /></a></div>
If a project has a good business case, then the next step is to figure out how big the project is. This requires that you expand the requirements sufficiently to<b> <span style="color: yellow;">estimate time and cost</span></b>.<br />
<br />
<span style="color: yellow; font-size: large;">When it comes to software -- size matters.</span><br />
<br />
Not only does size matter, you need to understand the level of <b><span style="color: yellow;">uncertainty </span></b>(requirements, technical, or skill) tied to your project to understand how much re-work or discovery will be necessary.<br />
<br />
<ul style="text-align: left;">
<li>Re-engineering a product with new technologies? (high technical uncertainty)</li>
<li>Building a new product with existing technologies? (high requirements uncertainty)</li>
<li>Building software with a team unfamiliar with the technology? (have high skills uncertainty)</li>
</ul>
<br />
<span style="color: yellow; font-size: large;">Skipping the time to get estimates is a major cause of project failure</span><br />
<br />
There are still executives that give engineering a few hours or a few days to estimate major projects and wonder why the projects go late or get cancelled.<br />
<br />
<h2>
Estimate Uncertainty</h2>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.vbpm.org/wp-content/uploads/2012/05/uncertainty.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.vbpm.org/wp-content/uploads/2012/05/uncertainty.png" /></a></div>
<span style="color: yellow; font-size: large;">Project methodology needs to take into account expected uncertainty.</span><br />
<br />
Projects with low uncertainty can be handled with a traditional project methodology; these projects can have their work breakdown structures elaborated and dependencies can be worked out ahead of time.<br />
<br />
Projects with moderate to high uncertainty will require <b><span style="color: yellow;">rework and discovery</span></b>. This must be built into the project plan or you need to switch to an Agile methodology. If you don't then there will be missing tasks on the project plan as well as task duration that is under-estimated.<br />
<br />
<span style="color: yellow; font-size: large;">Project tasks get stuck at 90% complete because the sources of uncertainty are not established a priori</span><br />
<br />
Executing a project with personnel that are not competent with the technologies that you want to use is essentially <b>professional malpractice</b>. If you must use existing personnel that don't know the technologies you want then you need to build in a large margin for training and rework over the project; <b><span style="color: yellow;">these projects will take at least 2x as long as your worst estimate</span></b>.<br />
<br />
<h2>
Focus on Early Defect Removal</h2>
Developer's say: "<span style="color: yellow;"><b>There is never enough time to write the code</b></span>". Statistics say, "<b><span style="color: yellow;">There is never enough time to find all the defects</span></b>" (see <a href="http://accelerateddevelopment.blogspot.com/2014/03/the-programmer-productivity-paradox.html" target="_blank">The Programmer Productivity Paradox</a>). To be successful you need to find defects as quickly as possible, especially since:<br />
<br />
<ul style="text-align: left;">
<li>If it costs <b>X</b> to find a defect pre-test </li>
<li>It costs <b>10X</b> to find it in QA</li>
<li>It costs <b>100X</b> to find it once deployed in the field</li>
</ul>
<br />
You do the math, it costs less to find defects before they get to QA. You are kidding yourself if you think that it is cost effective to have huge QA departments (see <a href="http://accelerateddevelopment.ca/blog_images/WWMCCS.png" target="_blank">The Cost of Not Doing Quality</a>).<br />
<br />
<h1>
Conclusion</h1>
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/MissingPieces.png" imageanchor="1" style="clear: right; display: inline !important; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/MissingPieces.png" /></a><span style="clear: left; color: black; display: inline !important; margin-bottom: 1em; margin-right: 1em; text-align: center;"></span><br />
Building software reliably and repeatably is not difficult. What is difficult is getting organizations to realize that there is a minimum set of processes that must be followed to have a successful project.<br />
<br />
<span style="color: yellow; font-size: large;">Organizations regularly skip one or more steps and wonder projects fail to come together and succeed.</span></div>
</div>
<!-- Blogger automated replacement: "https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Faccelerateddevelopment.ca%2Fblog%2Fwp-content%2Fuploads%2F2014%2F06%2Flaw-unintended-consequences.png&container=blogger&gadget=a&rewriteMime=image%2F*" with "https://blogger.googleusercontent.com/img/proxy/AVvXsEipgL7C27VYBFrRba4MAH3tY4h90bR7mj42UQVB6DZ2SoH7HZXiTIizwEeT6h_6YrrbTJDZfHxeHRvWEo9nyL2d9a9gy9zz_UZgnr_16tkm2FPIf7FJx1cYc_5lstcJdjO7faOIf2z9oEAUYVoIVljhPnLoY62GQLAQ1YIO8l-NqjCdzHj9_S6hTkcnGOZm-B-E2hQOLOMoMDrO8Td8Fzc2" --><!-- Blogger automated replacement: "https://blogger.googleusercontent.com/img/proxy/AVvXsEipgL7C27VYBFrRba4MAH3tY4h90bR7mj42UQVB6DZ2SoH7HZXiTIizwEeT6h_6YrrbTJDZfHxeHRvWEo9nyL2d9a9gy9zz_UZgnr_16tkm2FPIf7FJx1cYc_5lstcJdjO7faOIf2z9oEAUYVoIVljhPnLoY62GQLAQ1YIO8l-NqjCdzHj9_S6hTkcnGOZm-B-E2hQOLOMoMDrO8Td8Fzc2" with "https://blogger.googleusercontent.com/img/proxy/AVvXsEipgL7C27VYBFrRba4MAH3tY4h90bR7mj42UQVB6DZ2SoH7HZXiTIizwEeT6h_6YrrbTJDZfHxeHRvWEo9nyL2d9a9gy9zz_UZgnr_16tkm2FPIf7FJx1cYc_5lstcJdjO7faOIf2z9oEAUYVoIVljhPnLoY62GQLAQ1YIO8l-NqjCdzHj9_S6hTkcnGOZm-B-E2hQOLOMoMDrO8Td8Fzc2" -->Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-85089034187546920312014-06-09T12:19:00.001-07:002017-01-09T08:51:24.341-08:00Don't be a Slave to Your Tools<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/Abstract-Slave-300x267.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/06/Abstract-Slave-300x267.png" height="178" width="200" /></a></div>
Developers attach quickly to tools because they are <span style="color: yellow;"><strong>concrete</strong></span> and have well defined behavior. It is easier to learn a tool than to learn best practices or methodology.
Tools only assist in solving problems, they <span style="color: yellow;"><strong>can't solve</strong></span> the problem by themselves.<br />
<br />
A developer who <span style="color: yellow;"><strong>understands</strong></span> the problem can use tools to increase productivity and quality.
Poor developers don't <span style="color: yellow;"><strong>invest</strong></span> the time or effort to understand how to code properly and avoid defects. They spend their time learning how to use tools without understanding the purpose of the tool or how to use it effectively.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://functionalpathtraining.typepad.com/.a/6a00e5521cccd0883401676611800c970b-320wi" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://functionalpathtraining.typepad.com/.a/6a00e5521cccd0883401676611800c970b-320wi" height="200" width="166" /></a></div>
To some degree, this is partially the fault of the tool vendors. The tool vendors perceive an opportunity to make <strong><span style="color: yellow;">$$$$$</span> </strong>based on providing support for a common problems, such as:
<br />
<ul>
<li>defect trackers to help you manage defect tracking</li>
<li>version control systems to manage source code changes</li>
<li>tools to support Agile development (Version One, JIRA)</li>
<li>debuggers to help you find defects</li>
</ul>
There are many tools out there, but let's just go through this list and point out where developers and organizations get challenged. Note, all statistics below are derived from over 15,000 projects over 40 years.<sup>1</sup>
<br />
<h1>
Defect Trackers</h1>
Believe it or not, some organizations still don't have defect tracking software. I've run into a couple of these companies and you would not believe why. The effect of not having a defect tracking system is pretty severe, and there is evidence to prove this.<br />
<br />
<div class="negativeEmphasis" style="text-align: center;">
<b><span style="color: red; font-size: 125%;">Inadequate defect tracking methods: productivity -15%, quality -21%</span></b></div>
<div class="negativeEmphasis">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.zoho.com/bugtracker/images/busettingIcon.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.zoho.com/bugtracker/images/busettingIcon.png" /></a></div>
So we are pretty much all in <b><span style="color: yellow;">agreement </span></b>that we <b>need </b>to have defect tracking; we all know that the ability to manage more than a handful of defects is impossible without some kind of system<br />
<br />
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;">Automated defect tracking tools: productivity +18%, quality +26%</span></b></div>
<div class="positiveEmphasis">
<br /></div>
The problem is that developers <span style="color: yellow;"><b>disagree </b></span>over what might be the best defect tracking system. The real problem is that almost every defect tracking system is poorly set-up, leading to poor results. Virtually every defect tracking system when configured properly will yield tremendous benefits. The most common pitfalls are:
<br />
<ul>
<li>Introducing irrelevant <span style="color: yellow;"><strong>attributes</strong></span> into the defect lifecycle status, i.e. creation of statuses like <span style="color: yellow;"><strong>deferred</strong></span>, <span style="color: yellow;"><strong>won't fix</strong></span>, or <span style="color: yellow;"><strong>functions as designed</strong></span></li>
<li>Not being able to figure out if something is <span style="color: yellow;"><strong>fixed</strong></span> or not</li>
<li>Not understanding who is <span style="color: yellow;"><strong>responsible</strong></span> for addressing a defect</li>
</ul>
The tool vendors are happy to continue to provide new versions of defect trackers. However, using a defect tracker effectively has more to do with <span style="color: yellow;"><strong>how</strong></span> the tool is used rather than which tool is <span style="color: yellow;"><strong>selected</strong></span>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/10/Caution-Bug.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/10/Caution-Bug.png" height="176" width="200" /></a></div>
One of the most fundamental issues that organizations wrestle with is <span style="color: yellow;"><strong>what is a defect</strong></span>? A defect only exists if the code does not behave according to specifications. But what if there are <span style="color: yellow;"><strong>no specifications</strong></span> or the <span style="color: yellow;"><strong>specifications are bad</strong></span>? See <a href="http://accelerateddevelopment.blogspot.com/2013/10/its-not-bug-its.html" target="_blank">It's not a bug, it's...</a> for more information.<br />
<br />
Smart organizations understand that the way in which the defect tracker is used will make the biggest difference. Discover how to get more out of you defect tracking system in <a href="http://accelerateddevelopment.blogspot.com/2012/09/bug-tracker-hell-and-how-to-get-out.html">Bug Tracker Hell and How to Get Out</a>.<br />
<br />
Another common problem is that organizations try to manage enhancements and requirements in the defect tracking system. After all whether it is a requirement or a defect it will lead to a <span style="color: yellow;"><strong>code change</strong></span>, so why not put all the information into the defect tracker? Learn why managing requirements and enhancements in the defect tracking system is foolish in <a href="http://accelerateddevelopment.blogspot.com/2013/10/dont-manage-enhancements-in-bug-tracker.html" target="_blank">Don't manage enhancements in the bug tracker</a>.
<br />
<h1>
Version Control Systems</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.illustrationsof.com/royalty-free-hygiene-clipart-illustration-442348.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.illustrationsof.com/royalty-free-hygiene-clipart-illustration-442348.jpg" height="200" width="190" /></a></div>
Like defect tracking systems most developers have learned that version control is a necessary <span style="color: yellow;"><strong>hygiene</strong></span> procedure. If you don't have one then you are likely to catch a pretty serious disease (and at the least convenient time)
<br />
<br />
<div class="negativeEmphasis" style="text-align: center;">
<span style="color: red; font-size: 125%;"><b>Inadequate change control: productivity -11%, quality -16%</b></span></div>
<div class="negativeEmphasis">
<br /></div>
Virtually all developers <span style="color: yellow;"><strong>dislike</strong></span> version control systems and are quite vocal about what they can't do with their version control system. If you are the unfortunate person who decided on the version control system, just understand that there are hordes of developers out their <span style="color: yellow;"><strong>cursing</strong></span> you behind your back.<br />
<br />
Version control is simply chapter 1 of the story. Understanding how to chunk code effectively, integrate with continuous build technology, and making sure that the defects in the defect tracker refers to the correct version are just as important as the choice of version control system.
<br />
<h1>
Tools to support Agile</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://epicstart.net/wp-content/uploads/2012/11/AgileManifesto.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://epicstart.net/wp-content/uploads/2012/11/AgileManifesto.png" height="148" width="200" /></a></div>
Sorry <b><a href="http://www.versionone.com/?elq=00000000000000000000000000000000&elqCampaignId=" rel="nofollow" target="_blank">Version One</a></b> and <b><a href="https://www.atlassian.com/software/jira" rel="nofollow" target="_blank">JIRA</a></b>, the simple truth is that using an Agile tool does not make you agile, see <a href="http://accelerateddevelopment.blogspot.com/2014/05/agile-tools-do-not-make-you-agile.html" target="_blank">this</a>.<br />
<br />
These tools are most effective when you actually understand Agile development. One of my most effective Agile implementations only used Google docs in the implementation.<br />
<br />
Enough said.
<br />
<h1>
</h1>
<h1>
Debuggers</h1>
I have written extensively about why debuggers are not the best primary tools to track down defects. So I'll try a different approach here. :-)<br />
<br />
One of the most enduring sets of ratios in software engineering has been <span style="color: yellow;"><strong>1:10:100</strong></span>. That is, if the cost of tracking down a defect pre-test (i.e. before QA) is <span style="color: yellow;"><strong>1</strong></span>, then it will cost <span style="color: yellow;"><strong>10x</strong></span> if the defect is found by QA, and <span style="color: yellow;"><strong>100x</strong></span> if the defect is discovered in deployment by your customers.
Most debuggers are invoked when the cost function is in the <span style="color: yellow;"><strong>10x</strong></span> or <span style="color: yellow;"><strong>100x</strong></span> part of the process. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJEBu6wgOkoicKAubdbun23jNbE4F_FbGLS6r_DtSZ5v8g3X93zjLe8WcycyYv-cdUYWLSFwVQLjw40Fa_heZe-xjnf-n2fntgaXnOz4xPR1Gbmcwp_uN5TBHafxgTubYs-k2vwlevnxI/s1600/airbag.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJEBu6wgOkoicKAubdbun23jNbE4F_FbGLS6r_DtSZ5v8g3X93zjLe8WcycyYv-cdUYWLSFwVQLjw40Fa_heZe-xjnf-n2fntgaXnOz4xPR1Gbmcwp_uN5TBHafxgTubYs-k2vwlevnxI/s1600/airbag.jpg" height="200" width="200" /></a></div>
It is not that I dislike debuggers -- I simply believe in using <span style="color: yellow;"><strong>pre-test defect removal</strong> </span>strategies because they cost less and lead to higher code quality.
Pre-test defect removal strategies include:
<br />
<ul>
<li>Planning code, i.e. PSP</li>
<li>Test driven development, TDD</li>
<li>Design by Contract (DbC)</li>
<li>Code inspections</li>
<li>Pair programming for complex sections of code</li>
</ul>
You can find more information about this in:
<br />
<ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/04/defects-are-for-losers.html" target="_blank">Defects are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.ca/2013/05/not-planning-is-for-losers.html" target="_blank">Not planning is for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/07/debuggers-are-for-losers.html" target="_blank">Debuggers are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2014/05/are-debuggers-crutches.html" target="_blank">Are debuggers crutches</a></li>
</ul>
<h1>
</h1>
<h1>
Seldom Used Tools</h1>
Tools that can make a big difference but many developers don't use them:
<br />
<br />
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;">Automated static analysis: productivity +21%, quality +31%</span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;"><br /></span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;">Automated sizing in function points: productivity +17%, quality +24%</span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;"><br /></span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;">Automated quality and risk prediction: productivity +16%, quality +23%</span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;"><br /></span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;">Automated test coverage analysis: productivity +15%, quality +21%</span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;"><br /></span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;">Automated deployment support: productivity +15%, quality +20%</span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;"><br /></span></b></div>
<div class="positiveEmphasis" style="text-align: center;">
<b><span style="color: lime; font-size: 125%;">Automated cyclomatic complexity computation: productivity +15%, quality +20%</span></b></div>
<h1>
</h1>
<h1>
Important Techniques with No Tools</h1>
There are a number of techniques available in software development that tool vendors have not found a way to monetize on. These techniques tend to be <b><span style="color: yellow;">overlooked </span></b>by most developers, even though they can make a huge difference in productivity and quality.<br />
<br />
The <b>Personal Software Process</b> (PSP) and <b>Team Software Process</b> (TSP) were developed by <a href="http://www.sei.cmu.edu/watts/" target="_blank">Watts Humphrey</a>, one of the pioneers of building quality software.
<br />
<br />
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: 125%;"><b>Personal software process: productivity +21%, quality +31%<sup>2</sup></b></span></div>
<div class="positiveEmphasis" style="text-align: center;">
<sup><span style="color: lime; font-size: 125%;"><br /></span></sup></div>
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: 125%;"><b>Team software process: productivity +21%, quality +31%<sup>3</sup></b></span></div>
<ul>
</ul>
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: 125%;"><b>Code inspections: productivity +21%, quality +31%<sup>4</sup></b></span></div>
<div class="positiveEmphasis" style="text-align: center;">
<sup><span style="color: lime; font-size: 125%;"><b><br /></b></span></sup></div>
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: 125%;"><b>Requirement inspections: productivity +18%, quality +27%<sup>4</sup></b></span></div>
<div class="positiveEmphasis" style="text-align: center;">
<sup><span style="color: lime; font-size: 125%;"><b><br /></b></span></sup></div>
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: 125%;"><b>Formal test plans: productivity +17%, quality +24%</b></span></div>
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: 125%;"><b><br /></b></span></div>
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: 125%;"><b>Function point analysis (IFPUG): productivity +16%, quality +22%</b></span><br />
<div class="positiveEmphasis" style="text-align: left;">
<br />
The importance of inspections is covered in:</div>
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.com/2012/11/every-developer-is-aware-that-code.html" target="_blank">Inspections are not Optional</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/12/software-professionals-do-inspections.html" target="_blank">Software Professionals do Inspections</a></li>
</ul>
</div>
<h1>
Conclusion</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.funnyfbposts.com/wp-content/uploads/2011/10/incompetence.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.funnyfbposts.com/wp-content/uploads/2011/10/incompetence.gif" height="300" width="320" /></a></div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXSwPqH0qjHBDRoqVAl3j_OwkVuxQXgm4AhEj2WD6J6tlSPGFJO2NkvUP3XvGAoZorfhqQwtgxGXAkNAg7t1xlgCQGXAcAkgbImBM8Q3Cf4mWaHAEkU2ViGQevlcGYuw-869bfho9TUVo/s1600/MichaelJordan.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXSwPqH0qjHBDRoqVAl3j_OwkVuxQXgm4AhEj2WD6J6tlSPGFJO2NkvUP3XvGAoZorfhqQwtgxGXAkNAg7t1xlgCQGXAcAkgbImBM8Q3Cf4mWaHAEkU2ViGQevlcGYuw-869bfho9TUVo/s1600/MichaelJordan.png" /></a>There is definitely a large set of developers that assume that using a <b>tool </b>makes them <b><span style="color: yellow;">competent</span></b>.<br />
<br />
The reality is that learning a tool without learning the <span style="color: yellow;"><strong>principles</strong></span> that underlie the problem you are solving is like assuming you can beat the great Michael Jordan at basketball just because you have great running shoes.<br />
<br />
Learning tools is not a <span style="color: yellow;"><strong>substitute</strong></span> for learning how do do something competently.<br />
<br />
Competent developers are continually learning about techniques that lead to higher productivity and quality, whether or not that technique is supported by a tool.
<br />
<h1>
References</h1>
<ul>
<li>Gilb, Tom and Graham, Dorothy. <a href="http://www.amazon.com/Software-Inspection-Tom-Gilb/dp/0201631814/ref=sr_1_1?ie=UTF8&qid=1366836966&sr=8-1&keywords=software+inspections" target="_blank">Software Inspections</a></li>
<li><sup>1</sup>Jones, Capers. <a href="http://bit.ly/CJ_BestWorstPractices" target="_blank">SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS</a>. 2008.</li>
<li>Jones, Capers. <a href="http://www.amazon.ca/Economics-Software-Quality-Capers-Jones/dp/0132582201" target="_blank">The Economics of Software Quality</a>. 2011</li>
<li>Radice, Ronald A. <a href="http://www.amazon.com/High-Quality-Cost-Software-Inspections/dp/0964591316" target="_blank">High Quality</a></li>
<li><sup>2</sup>Watts, Humphrey. <a href="http://www.amazon.com/Introduction-Personal-Software-Process-Humphrey/dp/0201548097">Introduction to the Personal Software Process</a></li>
<li><sup>3</sup>Watts, Humphrey. <a href="http://www.amazon.com/Introduction-Software-Process-Watts-Humphrey/dp/020147719X">Introduction to the Team Software Process</a></li>
</ul>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-53140337813174425962014-05-16T10:24:00.000-07:002017-01-09T08:51:24.276-08:00Are Debuggers Crutches?<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/05/Woman-on-Crutches-103x300.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/05/Woman-on-Crutches-103x300.png" /></a></div>
Debuggers have become powerful tools, but like a drug have we become too dependent on them? Since poor developers spend 25 times more time in the debugger there is a likelihood that people are zoning out in the debugger instead of using other methods.
<br />
<br />
Defects are <span style="color: yellow;"><strong>common</strong></span>, but they are not not <span style="color: yellow;"><strong>necessary</strong></span>. They find their way into code because:
<br />
<ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/05/not-planning-is-for-losers.html" target="_blank" title="Not Planning is for Losers">Code pathways are not planned</a></li>
<li>Developers are inattentive when coding</li>
<li>Developers do not understand the requirements</li>
</ul>
<div class="smallPoint">
<div style="text-align: center;">
<span style="color: yellow; font-family: Trebuchet MS, sans-serif; font-size: large;"><b>Defect correction is only possible if you understand the code pathways, debuggers are not the best way to do this</b></span></div>
<br /></div>
Debuggers are commonly used by developer's to understand a problem, but just because they are <span style="color: yellow;"><strong>common</strong></span> does not make them the <span style="color: yellow;"><strong>best way</strong></span> to find defects. I'm not advocating a return to "the good old days" but there was a time when we did not have debuggers and we managed to debug programs.
<br />
<br />
<i>Note: in embedded systems it is very hard to get feedback if you do not use a debugger (or hardware debugger). This article is not addressed to embedded developers who rarely have an alternative to a debugger.</i><br />
<i><br /></i>
<br />
<h1>
Avoid Defects</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.informit.com/ShowCover.aspx?isbn=0201548097" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.informit.com/ShowCover.aspx?isbn=0201548097" height="320" width="192" /></a></div>
The absolute best way to remove defects is simply <span style="color: yellow;"><strong>not</strong></span> to create them in the first place. You can be skeptical, but things like the <a href="http://en.wikipedia.org/wiki/Personal_software_process" target="_blank" title="Personal Software Process">Personal Software Process</a> (PSP) have been used practically to prevent 1 of every 2 defects from getting into your code. Over thousands of projects:
<br />
<br />
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-family: Trebuchet MS, sans-serif; font-size: large;">The Personal Software Process increases productivity by 21% and increases code quality by 31%<sup>1<sup></sup></sup></span></div>
<br />
A study conducted by <a href="http://www.nist.gov/"><strong>NIST</strong></a> in 2002 reports that software bugs cost the U.S. economy <span style="color: yellow;"><strong>$59.5 billion</strong></span> annually. This huge waste could be cut in half if all developers focused on not creating defects in the first place.<br />
<br />
Not only does the <span style="color: yellow;"><strong>PSP</strong></span> focus on code planning, it also makes developers aware of how many defects they actually create. Here are two graphs that show the same group of developers and their defect injection rates before and after PSP training.<sup>2<sup>
<br />
<br />
<table>
<tbody>
<tr>
<td><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqdUQoocm2q8IcOMAIo80ZjvTljnhY0Vc9u0p9LQ0G0NbzaEeic_mW4gNDJRPUKeJLy8jo5TxefeU8W30lnesOkXO43eaVVa_VEpxiuyWaWSC8zdXyk_IbCnW5RD1CvPiIrHuSBY4U0Xk/s1600/PSP,+defects+per+KLOC,+before..png" width="300" />
</td>
<td><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgixUbBAD49OHH4cSTiTbazww7PwsBAxhOgJ7iv1LN8ozM8hRjTST1o47DqPVPKMy70kvVdXGNMTiDlGIqNfIxLvXtYOdxbNlhe0qJqiWdKf8L1he9K9tVeUaz21pW6mywrl-AGg-AZpcs/s1600/PSP,+defects+per+KLOC,+after.png" width="300" />
</td>
</tr>
<tr>
<td align="center"><b>Before PSP training</b></td>
<td align="center"><b>After PSP training</b></td>
</tr>
</tbody></table>
<br />
</sup></sup><br />
<h1>
Finding Defects</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/05/Unskilled-professional.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/05/Unskilled-professional.png" /></a></div>
Using a <span style="color: yellow;"><strong>debugger</strong></span> to understand the source of a defect is definitely one way. But if it is the best way then why do poor developers spend <strong><span style="color: yellow;">25 time</span>s</strong> more time in the debugger than a a good developer? (see <a href="http://accelerateddevelopment.blogspot.ca/2013/03/it-no-experience-required.html" target="_blank" title="No Experience Required!">No Experience Required</a>!)<br />
<br />
<div style="text-align: center;">
<span style="color: yellow; font-family: Trebuchet MS, sans-serif; font-size: large;"><b>Poor developers spend a week in the debugger for every 2 hours that good developer does</b></span></div>
<br />
No one is saying that debuggers do not have their uses. However, a debugger is a <span style="color: yellow;"><strong>tool</strong></span> and is only as good as the person using it. Focus on tools obscures lack of skill (see <a href="http://accelerateddevelopment.blogspot.ca/2014/05/agile-tools-do-not-make-you-agile.html" target="_blank" title="Agile Tools do NOT make you Agile">Agile Tools do NOT make you Agile</a>)<br />
<br />
If you are only using a debugger to understand defects then you will be able to remove a maximum of about <span style="color: yellow;"><strong>85%</strong></span> of all defects, i.e. 1 in 7 defects will always be present in your code.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/05/Orkin-man.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/05/Orkin-man.png" /></a></div>
Would it surprise you to learn that their are organizations that achieve <span style="color: yellow;"><strong>97% defect removal</strong></span><sup>3</sup>? Software inspections take the approach of looking for all defects in code and getting rid of them.
Learn more about software inspections and why they work here:
<br />
<ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/11/every-developer-is-aware-that-code.html" target="_blank" title="Inspections are not Optional">Inspections are not Optional</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/12/software-professionals-do-inspections.html" target="_blank">Software Professionals do Inspections</a></li>
</ul>
<br />
<div style="text-align: center;">
<b><span style="color: lime; font-family: Trebuchet MS, sans-serif; font-size: large;">Software inspections increase productivity by 21% and increases code quality by 31% </span></b></div>
<br />
Even better, people trained in software inspections tend to inject<span style="color: yellow;"><strong> fewer defects</strong></span> into code. When you become adept at parsing code for defects then you become much more <span style="color: yellow;"><strong>aware</strong></span> of how defects get into code in the first place.<br />
<br />
But interestingly enough, not only will developers inject fewer defects into code and achieve defect removal rates of up to 97%, in addition:
<br />
<br />
<div class="positiveEmphasis">
<div style="text-align: center;">
<b><span style="color: lime; font-family: Trebuchet MS, sans-serif; font-size: large;">Every hour spent in code inspections reduces formal QA by 4 hours</span></b></div>
</div>
<h1>
Conclusion</h1>
As stated above, there are times where a <span style="color: yellow;"><strong>skilled professional</strong> </span>will use a debugger correctly. However, if you are truly interested in being a software professional then:
<br />
<ul>
<li>You will learn how to plan and think through code before using the keyboard</li>
<li>You will learn and execute software inspections</li>
<li>You will learn techniques like PSP which lead to you injecting fewer defects into the code</li>
</ul>
<div class="smallPoint">
<div style="text-align: center;">
<b><span style="color: yellow; font-family: Trebuchet MS, sans-serif; font-size: large;">You are using a debugger as a crutch if it is your primary tool to reduce and remove defects</span></b><br />
<b><span style="color: yellow; font-family: Trebuchet MS, sans-serif; font-size: large;"><br /></span></b></div>
</div>
<h1>
Related Articles</h1>
Want to see more sacred cows get tipped? Check out:
<br />
<table>
<tbody>
<tr>
<td><ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/comments-are-for-losers.html" target="_blank">Comments are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/effectiveness-first-efficiency-second.html" target="">Efficiency is for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/07/debuggers-are-for-losers.html" target="_blank">Debuggers are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/01/developers-are-ones-who-inject-defects.html" target="_blank">Testing departments are for Losers</a></li>
</ul>
</td>
<td><img src="http://accelerateddevelopment.ca/blog_images/KillingSacredCows.png" />
</td>
</tr>
<tr>
<td></td>
<td align="center">Moo?</td>
</tr>
</tbody></table>
<i><br /></i>
<i>Make no mistake, I am the biggest "Loser" of them all. I believe that I have made every mistake in the book at least once :-)</i>
<br />
<i><br /></i>
<br />
<h1>
References</h1>
<ul style="text-align: left;">
<li>Gilb, Tom and Graham, Dorothy. <a href="http://www.amazon.com/Software-Inspection-Tom-Gilb/dp/0201631814/ref=sr_1_1?ie=UTF8&qid=1366836966&sr=8-1&keywords=software+inspections" target="_blank">Software Inspections</a></li>
<li><sup>1</sup>Jones, Capers. <a href="http://bit.ly/CJ_BestWorstPractices" target="_blank">SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS</a>. 2008.</li>
<li><sup>3</sup>Jones, Capers. <a href="http://www.amazon.ca/Economics-Software-Quality-Capers-Jones/dp/0132582201" target="_blank">The Economics of Software Quality</a>. 2011</li>
<li>Radice, Ronald A. <a href="http://www.amazon.com/High-Quality-Cost-Software-Inspections/dp/0964591316" target="_blank">High Quality
</a></li>
<li><sup>2</sup>Watts, Humphrey. <a href="http://www.amazon.com/Introduction-Personal-Software-Process-Humphrey/dp/0201548097">Introduction to the Personal Software Process</a></li>
</ul>
</div>
</div>
</div>
</div>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-89215192565068448582014-05-05T06:41:00.001-07:002017-01-09T08:51:24.356-08:00Agile tools do NOT make you Agile<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.formula1-dictionary.net/Images/F1_car_Ferrari.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.formula1-dictionary.net/Images/F1_car_Ferrari.jpg" height="279" width="320" /></a></div>
Ask yourself the following questions:<br />
<ul style="text-align: left;">
<li>Do great golf clubs make you a great golfer?</li>
<li>Does a formula one race make you an expert driver?</li>
<li><i>Do great development tools make you an expert developer?</i></li>
</ul>
<div>
Unless you are <b><span style="color: yellow;">delusional</span></b>, you know that the answer is <b><span style="color: yellow;">NO</span></b> to all these questions. An expert's performance can be dramatically improved with the right tools, but a beginner will not perform better with a great tool.</div>
<div>
<br /></div>
<div>
No matter how Agile-enabled tools like <a href="http://pm.versionone.com/try-VersionOne-agile-platform?gclid=CN3j0fGtjr4CFZJbfgoduC4AOg" target="_blank"><b>Version On</b>e</a> and <b><a href="https://www.atlassian.com/software/jira/agile" target="_blank">JIRA</a></b> become, using either tool will not make you Agile unless you understand what processes make agile development work.</div>
<div>
<br /></div>
<div>
I recently finished a contract at a large retailer where they use JIRA for an enterprise integration project. It was interesting to hear them use terms like <b><span style="color: yellow;">sprint</span></b> and <b><span style="color: yellow;">back log</span></b>; interesting because there was no regular sprint <b><span style="color: yellow;">cycle</span></b>, and the back log was only the <b><span style="color: yellow;">tickets</span></b> in the JIRA system. JIRA supports the notion of user stories (epics and stories) yet neither of these were being used correctly.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://epicstart.net/wp-content/uploads/2012/11/AgileManifesto.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://epicstart.net/wp-content/uploads/2012/11/AgileManifesto.png" height="237" width="320" /></a></div>
<div>
The problem isn't JIRA; the problem was that they believed that their process was Agile because JIRA supports agile development. <br />
<br />
<b><span style="color: yellow; font-size: large;">Being agile is about following the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a>.</span></b></div>
<div>
<br /></div>
<div>
Agile software development is <b><span style="color: yellow;">not informality</span></b>. Agile development has <b><span style="color: yellow;">fewer</span></b> formal practices than traditional waterfall development and those formal practices need to be adhered to (see <a href="http://accelerateddevelopment.blogspot.com/2013/05/agility-is-not-informality.html" target="_blank">Agility is not informality</a>). Agile development is <b><span style="color: yellow;">light weight</span></b> because it avoids activities that are unnecessary to the production of working code, not because it avoids rigour and formality.</div>
<div>
<br />
There are implementations of Scrum and XP that <b><span style="color: yellow;">WORK</span></b> and are agile because they implement sound development processes. However, there are also plenty of organizations that are implementing Scrum and XP incorrectly (see D<a href="http://accelerateddevelopment.blogspot.ca/2012/09/does-agile-hide-development-sins.html" target="_blank">oes Agile Hide Development Sins?</a>)<br />
<br />
Agile does not dictate that you have a fixed development <b><span style="color: yellow;">CYCLE</span></b>, but you can definitely succeed with one. What is required is that you break a project into multiple cycles where you iterate on development.<br />
Agile does not dictate <b><span style="color: yellow;">HOW</span></b> you keep your requirements (back log or stories) but you must have an effective requirements process. If your requirements process is broken then you will never succeed with agile.<br />
<br />
The Agile Manifesto puts the priority on things critical to development:<br />
<ul style="text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbyFcTevlSDkpi9Lf9vQ2mYqGUgCFzYIxkq-E55SfHyBtUjDoLANUvuLMOXSCY_4-UIsMo6CyoOdUaOASJGKzKnzUpC7HKPjY6I8a1ohFt8Vi2VbcQpkAw8GyEY337cARUECHY0-rmBxA/s1600/Untitled.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbyFcTevlSDkpi9Lf9vQ2mYqGUgCFzYIxkq-E55SfHyBtUjDoLANUvuLMOXSCY_4-UIsMo6CyoOdUaOASJGKzKnzUpC7HKPjY6I8a1ohFt8Vi2VbcQpkAw8GyEY337cARUECHY0-rmBxA/s1600/Untitled.png" height="194" width="200" /></a>
<li><span style="color: lime;">Individuals and interactions</span></li>
<li><span style="color: lime;">Working product</span></li>
<li><span style="color: lime;">Customer collaboration</span></li>
<li><span style="color: lime;">Responding to change</span></li>
</ul>
<div>
However, agile does not reject things in the right hand column, unless they get in the way of the above factors:</div>
<div>
<ul style="text-align: left;">
<li><span style="color: red;">Processes and tools</span></li>
<li><span style="color: red;">Comprehensive documentation</span></li>
<li><span style="color: red;">Contract negotiation</span></li>
<li><span style="color: red;">Following a plan</span></li>
</ul>
<div>
In particular, don't get get caught up in <b><span style="color: red;">Processes and tools</span></b>, i.e. Version One and JIRA. These tools can help you if you understand the core principles of agile development. If you don't, then these tools will leave you worse off than before. Unfortunately, the popularity of agile development has every tool maker scrambling to change their product to support agile.<br />
<br />
Tools will never extract or synthesize quality requirements and build quality code. The only way to get to proper understanding of a project is to put priority on <span style="color: lime; font-weight: bold;">individuals and interactions</span>; people and communication are the only way to solve problems -- tools are a secondary concern.</div>
</div>
<div>
<br /></div>
<div style="text-align: center;">
<b><span style="color: yellow; font-size: large;">Individuals and interactions OVER processes and tools</span></b></div>
<div>
<br /></div>
<div>
Agile development does not dictate a fixed development cycle, but it does require that any cycle must finish with a <b><span style="color: lime;">working product</span></b>. The emphasis always has to be production code and that is why periodic demonstrations of working code are essential.<br />
<br />
<div>
To accomplish this you need to understand your requirements, whether you have a back log or user stories. There are many times when properly written use cases can be used. Either way the requirements need to be correct and consistent, they need to be what the customer need, i.e. avoid hiding behind <b><span style="color: red;">excessive documentation</span></b>.<br />
<br /></div>
<div style="text-align: center;">
<b><span style="color: yellow; font-size: large;">Working Product OVER excessive documentation</span></b></div>
<br />
There is no way to get the requirements correct unless you have a strong working relationship with the customer. The customer often does not get the initial requirements correct and often development does not understand them. Focus on <b style="color: lime;">customer collaboration</b> is the key to mutual understanding. <br />
<br />
This is where most projects fall apart because both parties have a tendency to focus on <b><span style="color: red;">contract negotiatio</span></b><span style="color: red;"><b>n</b></span>. Contracts are necessary, but focusing on limiting liability and protecting yourself will not yield a relationship that leads to working software.<br />
<br />
<div style="text-align: center;">
<b style="text-align: center;"><span style="color: yellow; font-size: large;">Customer Collaboration OVER contract negotiation</span></b></div>
<br /></div>
</div>
<div>
You have to understand that <b><span style="color: red;">following a plan</span> </b>does not make sense when either requirements or technical uncertainty causes you to change development direction due to the need to <b><span style="color: lime;">respond to change</span></b>. <br />
<br />
It means making reliable estimates up front of all requirements, not just caving into pressure from upper management (see <a href="http://accelerateddevelopment.blogspot.ca/2012/02/why-senior-management-declared.html" target="_blank">Why Senior Management Declared Deadlines lead to Disaster</a>). This often means <b><span style="color: yellow;">adding time</span></b> to the projected end of the project when new requirements are discovered or technical challenges force work arounds. Unfortunately, many projects do not re-adjust the projected end date under these circumstances, which leads to a death march project (see <a href="http://accelerateddevelopment.blogspot.com/2013/01/death-march-mathematics.html" target="_blank">Death March Calculus</a>)<br />
<br />
<div style="text-align: center;">
<b><span style="color: yellow; font-size: large;">Responding to change OVER following a plan</span></b></div>
<br />
Agile development is about producing quality software by understanding the principles of the Agile Manifesto. Agile development is not about deluding yourself simply because you are using a tool that supports agile development. You can implement a very solid light weight agile solution using only spreadsheets.<br />
<br />
<div style="text-align: center;">
<b><span style="color: yellow; font-size: large;">Focus on being Agile first, then go find a tool</span></b></div>
<br /></div>
Other things that are compatible with agile development:<br />
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/comments-are-for-losers.html" target="_blank">Comments are for losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/11/every-developer-is-aware-that-code.html" target="_blank">Inspections are not optional</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/09/bug-tracker-hell-and-how-to-get-out.html" target="_blank">Bug Tracker Hell and How to Get Out</a></li>
</ul>
<br /></div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-27691420263807441072014-04-16T21:35:00.000-07:002017-01-09T08:51:24.212-08:00Productive Developers are Smart and Lazy<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjE2Hd2TaBlqukirv3MVDZkXPEklY1sJ90U3UZ6np9n3auG7pVcuglo1YZXbbTg2VigcG449HJ_SWfmdEgko76Jrws9BSBaR-xYWqIaL9iULfi4ry6B-Rh3zFD-mxnIKV2_AyTkUeJ3oSA/s1600/LazyCat.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjE2Hd2TaBlqukirv3MVDZkXPEklY1sJ90U3UZ6np9n3auG7pVcuglo1YZXbbTg2VigcG449HJ_SWfmdEgko76Jrws9BSBaR-xYWqIaL9iULfi4ry6B-Rh3zFD-mxnIKV2_AyTkUeJ3oSA/s1600/LazyCat.png" height="240" width="320" /></a></div>
When I use the terms <b><span style="color: yellow;">Smart</span></b>, <b><span style="color: yellow;">Lazy</span></b>, and <b><span style="color: yellow;">Developer</span></b>; I mean the following:<br />
<ul style="text-align: left;">
<li><b><span style="color: yellow;">Developer</span> </b>as in energetic and focused on building real-world code solutions</li>
<ul>
<li>Not a dreamer who never gets around to writing anything practical</li>
</ul>
<li><b><span style="color: yellow;">Smart</span> </b>as in able to think things through (i.e. not smart-ass)</li>
<li><b><span style="color: yellow;">Lazy</span> </b>as in <a href="http://en.wikipedia.org/wiki/Lazy_loading" target="_blank">lazy-loading</a>, that is taking time to write code (i.e. not couch potato)</li>
<ul>
</ul>
</ul>
<div>
<span style="font-family: inherit;">Good development is <b><span style="color: yellow;">lazy </span></b>development a.k.a. patient development; it happens when the developer spends the time necessary to think through all the pathways of the solution that he is developing <b>BEFORE</b> writing the code. That is <b><span style="color: yellow;">lazy-writing</span></b> of code, i.e. not writing code before the problem is understood. The more due diligence a developer does to make sure that he is writing the correct code will reduce the amount of code that needs to be written.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://blog.firstreference.com/wp-content/uploads/2010/05/inspection.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://blog.firstreference.com/wp-content/uploads/2010/05/inspection.jpg" width="150" /></a></div>
<div>
<span style="font-family: inherit;">This <b><span style="color: yellow;">due diligence</span></b> takes the form of:</span></div>
<div>
<ul style="text-align: left;">
<li>Really understanding the requirements and getting product management (business analysts) to be clear on what are the <b><span style="color: yellow;">ACTUAL </span></b>requirements</li>
<ul>
<li>They often are not given time to gather requirements</li>
<li>They often don't have access to the right subject matter experts</li>
<li>They sometimes have very poor abilities to synthesize consistent and complete requirements (see <a href="http://accelerateddevelopment.blogspot.ca/2014/02/when-ba-means-bllt-artist.html" target="_blank">When BA means B∪ll$#!t Artist</a>)</li>
</ul>
<li>Really making sure that you understand how you are interfacing to other developers on your team and other teams, this involves:</li>
<ul>
<li>collaboration in front of a white board</li>
<li>producing diagrams (UML and Visio)</li>
</ul>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.premier-ks.com/images/instructor-led-computer-training-sm.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.premier-ks.com/images/instructor-led-computer-training-sm.jpg" height="132" width="200" /></a></div>
<div>
It takes time to do this due diligence to make sure that you have <b><span style="color: yellow;">consistent requirements</span> </b>and to make sure that you will have <b><span style="color: yellow;">consistent interfaces</span></b><span style="color: yellow;"> </span>with your peers. However, developers are eager to start banging out code and spend hours at their desks banging out code. <br />
<br />
In reality, less than 5% of that time is spend productively (see <a href="http://accelerateddevelopment.blogspot.com/2014/03/the-programmer-productivity-paradox.html" target="_blank">The Programmer Productivity Paradox</a>). If you see developers spending 100% of their time staring at their screens with no human interaction then you are looking at some of the worst developers.</div>
</div>
<div>
<br /></div>
<div style="text-align: center;">
<b><span style="color: yellow; font-size: large;">It is a bad sign if developers are always coding</span></b></div>
<div>
<br /></div>
<div>
<span style="color: yellow;"><b>Productive developers</b> </span>are constantly checking their understanding of the requirements and making sure that they are staying in <b><span style="color: yellow;">sync </span></b>with their team's code. Productive developers are in <b><span style="color: yellow;">regular contact</span></b> with the product managers/business analysts and can often be seen <b><span style="color: yellow;">white boarding</span></b> with their peers and architects. There are definitely developers who use their years of experience to become more productive, in fact among the best developers:</div>
<div>
<ul>
<li style="margin: 0px; text-align: left;">the ratio of initial coding time was about 20 to 1</li>
<li style="margin: 0px; text-align: left;">the ratio of debugging times over 25 to 1</li>
<li style="margin: 0px; text-align: left;">program execution speed about 10 to 1</li>
<li style="margin: 0px; text-align: left;">program size 5 to 1</li>
</ul>
</div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://ownlessandlivemore.com/wp-content/uploads/2013/07/Life-Experience.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://ownlessandlivemore.com/wp-content/uploads/2013/07/Life-Experience.jpg" height="160" width="200" /></a></div>
However,<b> <span style="color: yellow;">in the aggregate</span></b>, developers do not become more productive over time (see <a href="http://accelerateddevelopment.blogspot.ca/2013/03/it-no-experience-required.html" target="_blank">No Experience Necessary!</a>), i.e. over thousands of developers there is no correlation between years of experience and productivity. In fact, we have measured productivity regularly 8 times over the last 50 years and years of experience do not correlate (in the aggregate) with productivity.</div>
<div>
<br /></div>
<div style="text-align: center;">
<b><span style="color: yellow; font-size: large;">Why is lazy writing of code so important?</span></b></div>
<div>
<br /></div>
<div>
Code is often written before the requirements are understood or gathered. In addition, quickly written code often fails to fit with everyone else's code; often, it is only during integration that this problem is discovered. Good developers are patient and realize that there is a cost to writing code quickly.<br />
<br />
<b><span style="color: yellow; font-size: large;">Developers become psychologically attached to their code </span></b><br />
<br />
Bad developers are <b><span style="color: yellow;">reluctant </span></b>to change poorly written code. Rather than rewrite suboptimal code, bad developers will simply <span style="color: yellow;"><b>add more code</b></span> to make up for deficiencies. Even worse, they tend to blame everyone else for having bad code. What you end up with is band-aid after band-aid that lead to a severely buggy and unstable system.</div>
<div>
<br /></div>
<div>
Don't get me wrong, good developers can find themselves in a situation where they have written <b><span style="color: yellow;">sub-optimal</span> </b>code. The difference is that a good developer will recognize a problematic section of code and:</div>
<div>
<ul style="text-align: left;">
<li>Refactor the code if the code is largely doing the right thing</li>
<li>Rewrite the the code otherwise</li>
</ul>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpgPwFJgGdFOcgJ6lKLdfcHsTjevG93dhuLs-HzOzCRdY_Jh72afi-zVfHzDzZLEuRQC7MTkgEaUskRm4G7JgNgs2pSjxjwQq8pt7xRtVQFhEngozuXQ07gE6SN7x0-GhrhYCohq2ripA/s1600/Untitled.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpgPwFJgGdFOcgJ6lKLdfcHsTjevG93dhuLs-HzOzCRdY_Jh72afi-zVfHzDzZLEuRQC7MTkgEaUskRm4G7JgNgs2pSjxjwQq8pt7xRtVQFhEngozuXQ07gE6SN7x0-GhrhYCohq2ripA/s1600/Untitled.png" width="170" /></a></div>
When developers produce and maintain sub-optimal code, it becomes <b><span style="color: yellow;">harder and harder</span></b> to change this code as time goes on. That is because their peers will need to write code that interfaces with the suboptimal code and build clumsy interfaces or work-arounds to make the code work. As the code base grows, too many later code units rely on the functionality of this initial code. Of course, the later code can do little to increase the stability of the code and bugs multiply when simple changes are made; in short, development becomes slower and slower.<br />
<br />
<div style="text-align: center;">
<b><span style="color: yellow; font-size: large;">When in doubt, be lazy and write code late</span></b></div>
</div>
</div>
<div>
<hr />
<h2 style="text-align: left;">
Other relevant articles:</h2>
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.com/2012/07/shift-happens.html" target="_blank">Shift Happens!</a></li>
<ul>
<li>Why failing to gather requirements early causes project failure</li>
</ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2014/01/no-business-case-project-failure.html" target="_blank">No Business Case == Project Failure</a></li>
<ul>
<li>Why not having business cases before project start is a recipe for failure</li>
</ul>
</ul>
</div>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-87834213490362974612014-03-09T17:14:00.000-07:002017-01-09T08:51:24.351-08:00The Programmer Productivity Paradox<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://cdn.shopify.com/s/files/1/0070/7032/files/Highly_Productive_Entrepreneurs_Shopify_Online_Shopping_Cart_Software_Blog.jpg?113268" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://cdn.shopify.com/s/files/1/0070/7032/files/Highly_Productive_Entrepreneurs_Shopify_Online_Shopping_Cart_Software_Blog.jpg?113268" height="130" width="200" /></a></div>
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">Programmers seem to be productive people.</span><br />
<br />
You always see them typing at their desks; they chafe for meetings to finish so that they can go back to their desks and code. When asked, they will say that <b>there is not enough time to produce the code</b>, and the sooner they can start coding, the sooner they will be done.
<br />
<div class="smallPoint">
<br /></div>
<div class="smallPoint" style="text-align: center;">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">So writing code must be the most important thing, correct?</span></div>
<br />
If the average programmer writes about 50 lines of production code a day. A 50,000 line program would take <strong>1,000</strong> man days to produce. The same 50,000 line listing can be entered by a programmer at about 1,000 lines a day or about <strong>50</strong> man days.
<br />
<div class="smallPoint">
<br /></div>
<div class="smallPoint">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">So what the heck are the developers doing for the other 950 days?</span></div>
<br />
Before addressing the apparent contradiction, lets make a simple observation. Many <b>methodologies </b>(RUP, XP, Agile, Waterfall, etc) and <b>programming languages</b> have been compared over thousands of projects and we have determined that programmers write between <strong>325</strong> and <strong>750</strong> lines of code (LOC) per month.<br />
<br />
That means the 1,000 LOC per month suggested above is optimistic<sup>1</sup>. Even if programmers do not average 50 lines of code per day, the following is clear<sup>2</sup>.<br />
<ul>
<li>Methodology does not explain the apparent productivity gap</li>
<li>No language accounts for the apparent productivity gap</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://greprep.me/wp-content/uploads/2011/02/combinations2.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://greprep.me/wp-content/uploads/2011/02/combinations2.png" height="165" width="200" /></a></div>
The reality is that only a <b><span style="color: yellow;">fraction </span></b>of a developer's time is actually spent writing production code. What developers are really doing is trying different combinations of code until they finally find the combination of code that works.<br />
<br />
Or more correctly, the <b><span style="color: yellow;">combination </span></b>that yields a solution that neither QA nor the business analyst complains about.<br />
<br />
That is why developers that <b><span style="color: yellow;">plan </span></b>their code before coding tend to outperform other developers. Few developers plan their code, but surprisingly, years of experience does not teach developers to learn to plan. Studies over <strong>40 years</strong> show that developer productivity does not change with years of experience. (see <a href="http://accelerateddevelopment.blogspot.ca/2013/03/it-no-experience-required.html">No Experience Required!</a>)
<br />
<br />
<div class="smallPoint" style="text-align: center;">
<span style="color: yellow; font-family: Helvetica Neue, Arial, Helvetica, sans-serif; font-size: large;">Years of experience do not lead to higher productivity</span></div>
<div class="smallPoint">
<br /></div>
Interestingly enough, there are methodologies that have been around for a long time that <b>emphasize planning code</b>. <a href="http://en.wikipedia.org/wiki/Watts_Humphrey">Watts Humphrey</a> is the created of the Personal Software Process (PSP)<sup>3</sup>. Using PSP has been measured to:
<br />
<br />
<div class="positiveEmphasis" style="text-align: center;">
<span style="color: lime; font-size: large;">PSP can raise productivity by 21% and quality by 31%</span></div>
<div class="positiveEmphasis">
<br /></div>
<a href="http://speckycdn.sdm.netdna-cdn.com/wp-content/uploads/2012/04/jquery-whiteboard-marker-notes.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://speckycdn.sdm.netdna-cdn.com/wp-content/uploads/2012/04/jquery-whiteboard-marker-notes.jpg" height="125" width="200" /></a>
If you are interested there are many other proven methods of raising code quality that are not commonly used (see <a href="http://accelerateddevelopment.blogspot.ca/2013/05/not-planning-is-for-losers.html">Not Planning is for Losers</a>).
<br />
<br />
<div class="smallPoint">
If your developers at their keyboard and not planning at a white board then odds are that your productivity is not as high as it could be.<br />
<br />
If developers are spending all their time trying different combinations of code until QA is satisfied, then it means that most of their time is really spent establishing correct pathways and removing defects. If you think about it, not having the correct pathways is a defect, so:</div>
<h1>
<span style="color: yellow; font-size: large; font-weight: normal;"><span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">The reality is that there is not enough time to find the defects in the quickly written code</span></span></h1>
<div class="smallPoint">
Interested in reducing defects in a cost-effective way? See <a href="http://accelerateddevelopment.blogspot.ca/2013/04/defects-are-for-losers.html" target="_blank">Defects are for Losers</a>.<br />
<h1>
Bibliography</h1>
<table>
<tbody>
<tr>
<td><sup>1</sup></td>
<td>The <b>The Mythical Man Month</b> is even more pessimistic suggesting that programmers produce 10 production lines of code per day</td>
</tr>
<tr>
<td><sup>2</sup></td>
<td>Jones, Capers and Bonsignour, Olivier. <b><a href="http://www.amazon.com/s/ref=nb_sb_ss_i_0_26?url=search-alias%3Dstripbooks&field-keywords=the%20economics%20of%20software%20quality&sprefix=the+economics+of+software+%2Cstripbooks%2C205&rh=i%3Astripbooks%2Ck%3Athe%20economics%20of%20software%20quality">The Economics of Software Quality</a>.</b> Addison Wesley. 2011</td>
</tr>
<tr>
<td><sup>3</sup></td>
<td>Watts, Humphrey. <a href="http://www.amazon.com/Introduction-Personal-Software-Process-Humphrey/dp/0201548097"><b>Introduction to the Personal Software Process</b></a>, Addison Wesley Longman. 1997</td>
</tr>
</tbody>
</table>
<hr />
<h1>
Articles in the "Loser" series</h1>
<table cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td>Want to see more sacred cows get tipped? Check out:
<br />
<ul style="text-align: left;">
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/comments-are-for-losers.html" target="_blank">Comments are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/04/defects-are-for-losers.html" target="_blank">Defects are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/07/debuggers-are-for-losers.html" target="_blank">Debuggers are for Losers</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2012/06/effectiveness-first-efficiency-second.html" target="">Efficiency is for Losers</a></li>
</ul>
</td>
<td><img src="http://accelerateddevelopment.ca/blog_images/KillingSacredCows.png" /></td>
</tr>
<tr>
<td></td>
<td class="tr-caption" style="text-align: center;"><b><span style="font-size: large;">Moo?</span></b></td>
</tr>
</tbody>
</table>
<i>Make no mistake, I am the biggest "Loser" of them all. I believe that I have made every mistake in the book at least once :-)</i></div>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-91892404490087492412014-02-17T20:05:00.001-08:002017-01-09T08:51:24.365-08:00When BA means B∪ll$#!t Artist<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<strong><span style="color: yellow;">BA</span> </strong> means <strong><span style="color: yellow;">Business Analys</span><span style="color: yellow;">t</span></strong>, but what makes for a good BA? When do you have a good BA and when do you have someone who isn't? Many projects fail at the beginning due to <strong>incomplete</strong>, <strong>inconsistent</strong>, and <strong>overly verbose</strong> analysis that then leads to incorrect project plans and projects heading in the wrong direction.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/02/Jumping+to+conclusions1.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/02/Jumping+to+conclusions1.jpg" /></a></div>
Business analysis consists of all facets of solving business problems. Business analysis is a role executed by project, product, and engineering managers as well as other people. However, there are people that do business analysis as their main role and we simply label them as <strong>business analysts</strong> or <strong>product managers</strong>.<br />
<br />
We shall stick to the term <a href="http://en.wikipedia.org/wiki/Business_analyst">business analyst</a> for simplicity.<b>
</b>
Business analysts perform a range of tasks including:<br />
<ul>
<li>Gathering requirements</li>
<li>Writing business cases and project charters</li>
<li>Performing gap analyses to incorporate new products</li>
</ul>
<div style="text-align: center;">
<span style="color: yellow; font-size: x-large;">Are your BAs any good? </span></div>
<br />
The success of many projects depend on the ability of the BA do correctly identify the problem you are trying to solve. If your BA is not competent then you are doomed before you start.<br />
<br />
Ever suspect that the people responsible for performing business analysis for you are not up for the challenge? Here are three simple questions; good business analysts will get <strong><span style="color: yellow;">all three correct</span></strong> and not take longer than 30 seconds.
<br />
<br />
<table border="1">
<tbody>
<tr style="bgcolor: yellow;">
<td bgcolor="yellow"></td>
<td bgcolor="yellow"><span style="color: black;"><strong>Context</strong></span></td>
<td bgcolor="yellow"><span style="color: black;"><strong>Question</strong></span></td>
</tr>
<tr valign="top">
<td><strong>#1</strong></td>
<td><img src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/02/MullerLyerLines.png" /></td>
<td>Which of these two lines is longer?</td>
</tr>
<tr valign="top">
<td><strong>#2</strong></td>
<td><img src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2014/02/paris_spring_puzzle.jpg" /></td>
<td>What does this sign say?</td>
</tr>
<tr valign="top">
<td><strong>#3</strong></td>
<td>I have two products whose prices add up to $1.10 and one product is $1 more than the other.</td>
<td>How much is the more expensive product?</td>
</tr>
</tbody>
</table>
<br />
The answers are:
<br />
<ol style="text-align: left;">
<li>The lines are the <span style="color: yellow;"><strong>same length</strong></span>
<ul>
<li>Take a ruler if you are not convinced</li>
</ul>
<ol>
</ol>
</li>
<li>Paris in <span style="color: yellow;"><strong>the the</strong></span> spring
<ul>
<li>Notice that <strong>the</strong> occurs twice</li>
</ul>
<ol>
</ol>
</li>
<li>The more expensive product is <span style="color: yellow;"><strong>$1.05</strong></span>
<ul>
<li>If the more expensive one had been $1 then the cheaper one would be $0.10 but then the expensive one would only be $0.90 more expensive than the cheaper one.</li>
</ul>
<ol>
</ol>
</li>
</ol>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://checkit.alexng.net/images/office-space-jump-to-conclusions-mat.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://checkit.alexng.net/images/office-space-jump-to-conclusions-mat.jpg" height="107" width="200" /></a></div>
These three questions illustrate that the mind can jump to <strong><span style="color: yellow;">conclusions</span> </strong>that are often wrong. The mind can be tricked because it assesses things quickly, i.e. jumps to conclusions. Only some people have the instinct to double check their results and check for personal bias.<br />
<br />
Most BAs are well educated; however, the interesting thing is that studies show that educated people are less able to see their biases and they jump to conclusions more readily than other people.<sup>1</sup> Even worse, well educated people have less of a tendency to check their conclusions than other people.
<br />
<br />
A <strong><span style="color: yellow;">good business analyst</span></strong> realizes that during analysis there will be situations where the mind will jump to conclusions. Many business analysts are asked to resolve conflicting requirements, recognize missing requirements, and deal with biases coming from many different sources. Unless you have the reflex of checking facts for consistency and eliminating bias then you won't make a good business analyst.
<br />
<br />
<div class="point">
<div style="text-align: center;">
<span style="color: yellow; font-size: x-large;"><b>So what is the quality of your BAs?</b></span></div>
</div>
<h1>
</h1>
<h1>
Other articles</h1>
<ul>
<li><a href="http://accelerateddevelopment.blogspot.com/2014/01/no-business-case-project-failure.html">No Business Case == Project Failure</a></li>
<li><a href="http://accelerateddevelopment.blogspot.com/2013/03/it-no-experience-required.html">No Experience Required</a></li>
</ul>
<h1>
Bibliography</h1>
<div style="padding-left: 30px;">
<sup>1</sup> West, Richard F. and Meserve, Russel J. <strong><i>Cognitive Sophistication does not Attenuate the Bias Blind Spot</i>.</strong> Journal of Personality and Social Psychology.</div>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-90195058151353074342014-01-16T15:08:00.001-08:002017-01-09T08:51:24.361-08:00No Business Case == Project Failure<div dir="ltr" style="text-align: left;" trbidi="on">
A <span style="color: yellow;"><b>business case</b></span> comes between a bright idea for a software project and the creation of the software project.
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://img.bilgipaneli.com/large/business-briefcase-attache-suitcase-img.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><br /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl5YFBiUKs5AX3Ww98fhvtUQNTnVGBZUpDJN4_D4UA9npiEgqQtefE4fBazUWdgDY8VpDy1wWzSJOCu_GbZQ5z0IwrCFWnGaSYddkuBVWrj4PmyNTw1c5Ojf1lUDWQTjNimE00PAtFs6A/s1600/Project+Timeline,+Business+Case.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl5YFBiUKs5AX3Ww98fhvtUQNTnVGBZUpDJN4_D4UA9npiEgqQtefE4fBazUWdgDY8VpDy1wWzSJOCu_GbZQ5z0IwrCFWnGaSYddkuBVWrj4PmyNTw1c5Ojf1lUDWQTjNimE00PAtFs6A/s1600/Project+Timeline,+Business+Case.png" /></a></div>
<ul>
<li>To - idea to have a project is born</li>
<li>Tcheck - formal or informal business case</li>
<li>Tstart - project is initiated</li>
<li>Tend - project finishes successfully or is abandoned</li>
</ul>
Not all ideas for software projects make sense. In the yellow zone above, between idea and project being initiated, some <span style="color: yellow;"><b>due diligence</b></span> on the project idea should occur. This is where you do the business case, even if only informally on the back of a napkin.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://newspaper.li/static/aa377ba8938d2351ddf0a028f75480ad.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://newspaper.li/static/aa377ba8938d2351ddf0a028f75480ad.gif" height="200" width="181" /></a></div>
The business case is where you pause and and estimate whether the project is worth it, i.e.<b><span style="color: yellow;"> will this project leave you better off than if you did not do it</span></b>. For those who want precise definitions the project should be <a href="http://en.wikipedia.org/wiki/Net_present_value">NPV</a> +ve. In layman's terms, the project should leave the organization better off on it's bottom line or at least improve skill levels so that other projects are better off.
<br />
<br />
<div class="point">
<span style="color: yellow;"><span style="font-size: large;"><b>Projects that do not improve skills or the bottom line are a failure.</b></span></span></div>
<div class="point">
<br /></div>
Out of 10 software projects (see <a href="http://accelerateddevelopment.blogspot.ca/2012/05/executives-understanding-your-chances.html">Understanding your chances</a>):
<br />
<ul>
<li>3 are successful
</li>
<li>4 are challenged, i.e. over cost, over budget, or deliver much less functionality</li>
<li>3 will fail, i.e. abandoned</li>
</ul>
This means that the base rate of success for any software project is only 3 out of 10. Yet <span style="color: yellow;"><b>executives</b></span> <span style="color: yellow;"><b>routinely</b></span> execute projects assuming that they can not fail, even though the project team may know that the project will be a failure from day 1.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.vbpm.org/wp-content/uploads/2012/05/uncertainty.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.vbpm.org/wp-content/uploads/2012/05/uncertainty.png" height="142" width="200" /></a></div>
Business cases give executives a chance to stop dubious projects before they start. (see <a href="http://accelerateddevelopment.blogspot.ca/2013/10/stupid-is-as-stupid-does.html" target="_blank" title="Stupid is as Stupid Does">Stupid is as Stupid Does</a>) Understanding how formal the business case needs to be comes down to <span style="color: yellow;"><b>uncertainty</b></span>. There are three key uncertainties with every project:
<br />
<ul>
<li>Requirements uncertainty</li>
<li>Technical uncertainty</li>
<li>Skills uncertainty</li>
</ul>
When there is a <span style="color: yellow;"><b>moderate</b></span> amount of uncertainty in any of these three areas then a formal business case with cash flows and risks needs to be prepared.
<br />
<br />
<h1>
Requirements Uncertainty</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://photos-h.ak.fbcdn.net/hphotos-ak-ash3/t1/45065_613186395403037_647629777_n.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://photos-h.ak.fbcdn.net/hphotos-ak-ash3/t1/45065_613186395403037_647629777_n.jpg" height="320" width="275" /></a></div>
Requirements uncertainty is what leads to <span style="color: yellow;"><b>scope shift</b></span> (scope creep). <br />
<br />
The probability of a project failing is proportional to the number of unknown requirements when the project starts (see <a href="http://accelerateddevelopment.blogspot.ca/2012/07/shift-happens.html" title="Shift Happens">Shift Happens</a>).<br />
<br />
Requirements uncertainty is only low for two particular projects:<br />
<ol style="text-align: left;">
<li>re-engineering a project where the requirements do not change</li>
<li>the next minor version of a software project. </li>
</ol>
For all other software projects the requirements uncertainty is moderate and a formal business case should be prepared.<br />
<br />
<div class="point">
<span style="color: yellow;"><span style="font-size: large;"><b>Projects new to you have high requirements uncertainty.</b></span></span><br />
<span style="color: yellow;"><span style="font-size: large;"><b><br /></b></span></span></div>
<h1>
Technical Uncertainty</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://steadfastlutherans.org/wp-content/uploads/2013/01/square-peg.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://steadfastlutherans.org/wp-content/uploads/2013/01/square-peg.jpg" height="199" width="200" /></a></div>
Technical uncertainty exists when it is not clear that all requirements can be <span style="color: yellow;"><b>implemented</b></span> using the selected technologies at the level of performance required for the project. Technical uncertainty is only low when you have a strong understanding of the requirements and the implementation technology. Uncertainty and risk are two different animals (see
<a href="http://accelerateddevelopment.blogspot.ca/2012/08/uncertainty-and-risk-in-software.html">Uncertainty Trumps Risk in Software Development</a>)<br />
<br />
When there is only a moderate understanding of the requirements or the implementation technology then you will encounter the following problems:<br />
<ul>
<li>Requirements that get clarified late in the project that the implementation technology will not support</li>
<li>Requirements that can not be implemented once you improve your understanding of the implementation technology</li>
</ul>
Therefore technical uncertainty is high when you are doing a project for the first time and requirement uncertainty is high. Technical uncertainty is high when you are using new technologies, i.e. shifting from Java to .NET or changing GUI technology.
<br />
<br />
<div class="point">
<span style="font-size: large;"><b><span style="color: yellow;">Projects with new technologies have moderate to high uncertainty.</span></b></span><br />
<span style="font-size: large;"><b><span style="color: yellow;"><br /></span></b></span></div>
<h1>
Skills Uncertainty</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://sharebestpracticesblog.com/wp-content/uploads/2011/04/unskilled-labor.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://sharebestpracticesblog.com/wp-content/uploads/2011/04/unskilled-labor.jpg" height="212" width="320" /></a></div>
Skills uncertainty comes from using resources that are unfamiliar with the requirements or the implementation technology. Skills uncertainty is a <span style="color: yellow;"><b>knowledge problem</b></span>. <br />
<br />
Skills uncertainty is only low when the resources understand the current requirements and implementation technology. <br />
<br />
Resources unfamiliar with the requirements will often implement requirements in a suboptimal way when requirements are not well written. This will involve rework; the worse the requirements are understood the more rework will be necessary.<br />
<br />
Resources unfamiliar with the implementation technology will make mistakes choosing implementation methods due to lack of familiarity with the philosophies of the implementation libraries. Often after a project is complete, resources will understood that different implementation tactics should have been used.<br />
<br />
<h1>
Formal or Informal Business Cases?</h1>
An informal business case is possible only if the requirements, technical, and skills uncertainty is low. This only happens in a few situations:<br />
<ul>
<li>Replacing a system where the requirements will be the same and the implementation technology is well understood by the team</li>
<li>The next minor version of a software system</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.tie-a-tie.net/images/black-tie-attire.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.tie-a-tie.net/images/black-tie-attire.jpg" height="200" width="115" /></a></div>
Every other project requires a formal business case that will quantify what kind of uncertainty and what degree of uncertainty exists in the project. At a minimum project managers facing moderate to high uncertainty should be motivated to push for a business case (see <a href="http://accelerateddevelopment.blogspot.ca/2013/10/stupid-is-as-stupid-does.html" target="_blank" title="Stupid is as Stupid Does">Stupid is as Stupid Does</a>).<br />
<br />
Here is a list of projects that tend to be accepted without any kind of real business case that quantifies the uncertainties:<br />
<ul>
<li>Change of implementation technology
<ul>
<li>Moving to object-oriented technology if you don't use it</li>
<li>Moving from .NET to Java or vice versa</li>
</ul>
</li>
<li>Software projects by non-software companies</li>
<li>Using generalists to implement technical solutions</li>
<li>Replacing systems with resources unfamiliar with the requirements
<ul>
<li>Often happens with outsourcing</li>
</ul>
</li>
</ul>
<div class="point">
<b><span style="font-size: large;"><span style="color: yellow;">Projects with moderate to high risks and no business case are doomed to fail.</span></span></b><br />
<b><span style="font-size: large;"><span style="color: yellow;"><br /></span></span></b></div>
<h1>
Related articles</h1>
<ul>
<li><a href="http://accelerateddevelopment.blogspot.ca/2013/03/it-no-experience-required.html">No Experience Necessary!</a>
<ul>
<li>Surprisingly there is no correlation between years of experience and productivity. This has been verified over 40 years.</li>
</ul>
</li>
<li><a href="http://accelerateddevelopment.blogspot.ca/2013/01/stop-it-no-really-stop-it.html">Stop it! No, Really Stop It!</a>
<ul>
<li>5 worst practices that software organizations commonly practice that they need to stop right away</li>
</ul>
</li>
</ul>
</div>Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0tag:blogger.com,1999:blog-3605277307868077948.post-43900763124116155522013-12-03T10:07:00.001-08:002017-01-09T08:51:24.251-08:00What the Heck are Non-Functional Requirements?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.consultasifrs.com/images/fotos/novedad_78.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.consultasifrs.com/images/fotos/novedad_78.jpg" height="133" width="200" /></a></div>
If functional requirements are for the end-users (customers), then who are the non-functional requirements for?<br />
<br />
<span style="color: yellow; font-family: inherit; font-size: large;">Non-functional requirements are for those that install and maintain operational code, i.e. the help desk and operators</span><br />
<br />
Every developer needs to be aware of what those non-functional requirements are and why operations personnel and help desk personnel are <span style="color: yellow;"><b>indirect</b></span> <b><span style="color: yellow;">customers</span></b> that are really important. There is no way for these guys to be unhappy and it not to back up into development as an urgent problem!<br />
<br />
<h1>
Functional Requirements</h1>
<span style="color: yellow;"><b>Functional requirements</b></span> are baked into the code that developer's deliver (interpreted or compiled). Events from input devices (network, keyboard, devices) trigger functions to convert input into output -- all functions have the form:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/12/Function.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/12/Function.png" height="50" width="400" /></a></div>
<br />
This is true whether you use an object-oriented language or not.<br />
<br />
<span style="color: yellow;"><b>Non-functional</b></span> requirements involve everything that surrounds a functional code unit. Non-functional requirements concern things that involve time, memory, access, and location:<br />
<br />
<table border="1">
<tbody>
<tr style="valign: top;">
<td style="valign: top;">Performance</td>
<td style="valign: top;"><ul>
<li>Server must be able to handle 100 transactions a second</li>
<li>End user must have less than 1 second response</li>
</ul>
</td>
</tr>
<tr style="valign: top;">
<td style="valign: top;"><i><span style="color: yellow;">Availability</span></i></td>
<td style="valign: top;"><ul>
<li>The service has to be available 99.99% of the time during the service hours</li>
</ul>
</td>
</tr>
<tr style="valign: top;">
<td style="valign: top;"><i><span style="color: yellow;">Capacity</span></i></td>
<td style="valign: top;"><ul style="text-align: left;">
<li>During service hours the server must support 700 simultaneous users</li>
</ul>
</td>
</tr>
<tr style="valign: top;">
<td style="valign: top;"><i><span style="color: yellow;">Continuity</span></i></td>
<td style="valign: top;"><ul style="text-align: left;">
<li>Service is resilient to disk, machine, and operational center failure</li>
</ul>
</td></tr>
<tr style="valign: top;">
<td style="valign: top;"><i><span style="color: yellow;">Security</span></i></td>
<td style="valign: top;"><ul style="text-align: left;">
<li>Ensure that only people authorized to access the service can</li>
<li>Ensure that data is never corrupted due to illegal activity or machine failure</li>
</ul>
</td></tr>
</tbody></table>
<br />
I won't spend any time on performance because this is the non-functional requirement that everyone understands.<br />
<br />
Non-functional requirements are slightly different between desktop applications and services; this article is focused on non-functional requirements for services.<br />
<br />
If you have any knowledge of <span style="color: yellow;"><b>ITIL</b></span> you will recognize that the highlighted items deal with the <span style="color: yellow;"><b>warranty</b></span> of a service. In fact, the functional requirements involve the <span style="color: yellow;"><b>utility</b></span> of a service, the non-functional requirements involve the warranty of a service.
<br />
<br />
<h1>
Availability</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.awanbee.com/lite/wp-content/uploads/2010/10/availability.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="135" src="https://www.awanbee.com/lite/wp-content/uploads/2010/10/availability.png" width="200" /></a></div>
Availability is about making sure that a service is available when it is supposed to be available. Availability is about a <span style="color: yellow;"><b>Configuration Item</b></span> (CI) in the environment of the operations center that specifies how the code is accessed. Availability is decided independently of the code and is at best part of the <span style="color: yellow;"><b>Service Design Package</b></span> (SDP) that is delivered to the operations department.<br />
<br />
Developer's need to be aware of single-points of failure (i.e. services hard-coded to a specific IP) which causes fits in operations that are not running virtual machines (VM) that can have virtual IPs . The requirement to create code that is not reliant on static IPs or specific machines is a non-functional requirement. Availability is simplified in operations if the code is resilient enough to allow itself to easily move (or be replicated) among servers.
<br />
<br />
Availability non-functional requirements include:<br />
<ul>
<li>Code to verify that customers are in their user windows</li>
<li>Automatic installation of <b>CI</b> or mechanisms</li>
<li>Ability to detect and prevent manual errors for a <b>CI</b></li>
<li>Ability to easily move code between servers</li>
</ul>
<h1>
Capacity</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.aquamanplumbing.com.au/overflowing_bathroom.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.aquamanplumbing.com.au/overflowing_bathroom.jpg" height="199" width="200" /></a></div>
Capacity is about delivering enough functionality when required. If you ask a web service to supply 1,000 requests a second when that server is only capable of 100 requests a second then something will fail. <br />
<br />
<span style="color: yellow;">This may look like an availability issue, but it is caused because you can't handle the capacity requested.</span><br />
<br />
Internet services can't provide enough capacity with a single machine and operations personnel need to be able to run multiple servers with the same software to meet capacity requirements. The ability to run multiple servers without conflicts is a non-functional requirement. The ability to take a failing node and restart it on another machine or <b>VM</b> is a non-functional requirement.<br />
<br />
Capacity non-functional requirements include:<br />
<ul>
<li>Ability to run multiple instances of code easily</li>
<li>Ability to easily move a running code instance to another server</li>
</ul>
<h1>
Continuity</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.moillusions.com/wp-content/uploads/photos1.blogger.com/pictures/MoebiusAntsSmall.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.moillusions.com/wp-content/uploads/photos1.blogger.com/pictures/MoebiusAntsSmall.gif" /></a></div>
Continuity involves being able to be robust against major interruptions to a service, these include power outages, floods or fires in an operational center, or any other disaster that can disrupt the network or physical machines.<br />
<br />
Where availability and capacity often involve redundancy inside a single operation center, continuity involves geographic and network redundancy. Continuity at best involves having multiple servers that can work in geographically distributed operation centers. At worst, you need to be able to have a master-slave fail over model with the ability to journal transactions and eventually bring the master back up.<br />
<br />
Continuity non-functional requirements include:<br />
<ul>
<li>Resilience of a code base to potential network outages, i.e. ability to retry transactions or find a new server</li>
<li>Making sure that correct error messages are returned when physical failures are encountered, i.e. if the network is unavailable then don't give the end-user a message "Customer record has errors, please correct".</li>
<li>Ability to recognize inconsistent data and not continue to corrupt data inside the database.</li>
</ul>
<br />
<br />
<span style="font-weight: bold;"><span style="font-size: x-large;">Security</span></span> <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/12/SecurityBouncer-small.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://accelerateddevelopment.ca/blog/wp-content/uploads/2013/12/SecurityBouncer-small.png" /></a></div>
Security non-functional requirements concern who has access to functions and preventing the integrity of data from being corrupted.<br />
<br />
Where access is concerned, how difficult will it be for operations personnel or help desks to set up security for users? <br />
<br />
Developer's build in different levels of access into their applications without considering how difficult it will be for a 3rd party (help desk or operations) to set-up end users.<br />
<br />
Data integrity is another non-functional requirement. Developer's need to consider how their applications will behave if the program encounters corrupted data due to machine or network failures. This is not as important an issue in environments using RAID or redundant databases.<br />
<br />
Security non-functional requirements include:<br />
<ul>
<li>Ease of a help desk to set up a new user on an application</li>
<li>Ability to configure a user's rights to enable them only to access the functions that they have a right to</li>
<li>Ensuring through data redundancy or consistency algorithms that data is not corrupted</li>
</ul>
<br />
<br />
<h1>
When You Forget Non-Functional Requirements...</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFkPeBY6a3VOSgHFvgq4kuU0WWMqi1uQhm876j0LB85K95r6OYVkOfPtNc6Be1U4zov1OO4e0vjHX4xpbMrextdX7DkXfyQ-0UhlVNy168iNf6ichGlpAQxACykb6znv8WqWc55zZBdDA/s1600/elephant+remember.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFkPeBY6a3VOSgHFvgq4kuU0WWMqi1uQhm876j0LB85K95r6OYVkOfPtNc6Be1U4zov1OO4e0vjHX4xpbMrextdX7DkXfyQ-0UhlVNy168iNf6ichGlpAQxACykb6znv8WqWc55zZBdDA/s200/elephant+remember.jpg" height="193" width="200" /></a></div>
Commonly start-ups are so busy setting up their services that the put non-functional requirements on the <b><span style="color: yellow;">back burner</span></b>. The problem is that there are non-functional requirements that need to be designed into the architecture when software is created.<br />
<br />
For example, it is easy to be <span style="color: yellow;"><b>fooled</b></span> into building software that is tied to a single machine, however, this will not scale in operations and cause problems later on. One of the start-ups I was with built a server for processing credit/debit card transactions without considering non-functional requirements (capacity, continuity). <br />
<br />
<div style="text-align: center;">
<span style="font-size: large;"> <span style="color: yellow;"><b>It cost more to add the non-functional requirements than it cost to develop the software!</b></span></span></div>
<br />
Every non-functional requirement that is not thought through at the inception of a project will often represent significant work to add later on. Every such project is a <span style="color: yellow;"><b>0 function point</b></span> project that will require <span style="color: yellow;"><b>non zero cost</b></span>!<br />
<br />
Generally availability, capacity, and continuity is not a problem for services developed with cloud computing in mind. However, there are thousands of legacy services that were developed before cloud computing was even possible.<br />
<br />
<div class="emphasis" style="text-align: center;">
<span style="color: yellow;"><span style="font-size: large;">If you are developing a new service then make sure it is cloud enabled!</span></span></div>
<h1>
</h1>
<h1>
Operations People are People Too</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://images.govirtualassistant.com/help-desk-virtual-assistant1.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://images.govirtualassistant.com/help-desk-virtual-assistant1.jpg" height="213" width="320" /></a></div>
Make no mistake, operations and help desk personnel are fairly <b>resourceful</b> and have learned how to manage software where non-functional requirements are not addressed by the developers.<br />
<br />
Hardware and OS solutions exist for making up for poorly written software that assumes single machines or does not take into account the environment that the code is running in, but that can come at a fairly <span style="color: yellow;"><b>steep cost</b></span> in infrastructure.
<br />
<br />
The world has moved to services and it is no longer possible for developers to ignore the non-functional requirements involved with the code that they are developing. Developer's that think through the non-functional requirements can <b><span style="color: yellow;">reduce costs dramatically</span></b> on the bottom line and quality of service being delivered.<br />
<br />
The guys that run operational centers and help desks are <span style="color: yellow;"><b>customers </b></span>that are only slightly less important than the end-user. Early consideration of the non-functional requirements makes their lives easier and makes it much easier to sell your software/services.
It is no longer possible for competent developers to be unaware of non-functional requirements.
<br />
<br />
<hr />
<br />
<b><span style="font-size: x-large;">Other Articles</span></b><br />
<table border="1" style="width: 100%px;">
<tbody>
<tr>
<td><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9eQgI8YIWcgn7oUpPEAk4gst3W3F2FnTXdSDfktr8mfiu1Df7el1Mc84CizbjVI4S1wItJL0GqyqcbxYCpghMfounMM9dXMhim6PQDLpmxnuIvKwkYN_6nbh72diUfZNpAZ8nN3f7Cro/s1600/NoExperienceNecessary.png" width="150" /></td>
<td><a href="http://accelerateddevelopment.blogspot.com/2013/03/it-no-experience-required.html" title="No Experience Required!">No Experience Necessary</a>
</td>
<td>Counter-intuitive evidence why years of experience does not make developers more productive
</td>
</tr>
<tr>
<td><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_2dPoDEidKZmuMlkZ2LvtJ17iydjry5u22MdcSzWxdFjaPirlQnk2tEOM1BkzOXWx_Hqk_CYZjuJwKqG7-NN8fvQP7WqJzMC1Y-WwNC37easq7Ftzw0vJrjrJyu7l58RuBT5CPohYMf4/s200/ShiftHappens.png" width="150" /></td>
<td><a href="http://accelerateddevelopment.blogspot.com/2012/07/shift-happens.html">Shift Happens</a>
</td>
<td>Why scope shift on development projects is inevitable and why not capturing requirements at the start of a project can doom it to failure.
</td>
</tr>
<tr>
<td><img src="http://accelerateddevelopment.ca/blog_images/EngineeringFail/fail-owned-building-door-fail.jpg" width="150" /></td>
<td><a href="http://accelerateddevelopment.blogspot.ca/2012/11/every-developer-is-aware-that-code.html" title="Inspections are not Optional">Inspections are not Optional</a>
</td>
<td>Software inspections are intensive but evidence shows that for each hour of inspection you can reduce QA by 4 hours!
</td>
</tr>
</tbody></table>
</div>
Accelerated Developmenthttp://www.blogger.com/profile/05820360412449920754noreply@blogger.com0