An Insight into Continuous Integration


Continuous Integration (CI) is a Software Engineering practice that ensures the quality of a software product by running a build after every change of the code. Throughout the years CI has proved to be an essential software development technique. However, not all aspects of CI are relevant for every single software project. Moreover, some people misuse the CI concepts and end up failing to produce good results.

I have recently finished an Industrial Placement at a software design company. This article will present my thoughts on CI based on the experience I gained during my work within the company.



CI is based on daily integration of work from all the members of a team. The aim is to detect errors as early as possible in the development process and fix the bugs immediately in order to reduce project time.

In his article [1], Fowler presents the following main concepts of CI:

  • Singe source code repository
  • Automated, self-testing and fast builds
  • Daily commits to the mainline by all the team members but only after a successful build
  • Replicate the production environment in order to test the code
  • Make latest deliverables available to everyone
  • Automate the deployment



Given the descriptions of CI many people might think that it is only worth applying it in projects with more than one team member. This is definitely not the case. The project I worked on within the company represented my master thesis. Therefore I was the only developer in the project and I was coding everything myself. Although it took me a while to get used to the company’s version control system (SVN) and their rules I soon realised how useful CI was. I really valued the security of having my code automatically built, tested and deployed. Moreover, by running it on another machine ensured that my code could be safely used and updated by other engineers after my departure.

Although I was assigned an individual project I was still a part of a bigger team which allowed me to understand how they use CI. I have seen that there is no right way to implement CI. In order for it to be successful, its practices have to be modelled with respect to each company, project and team. In his article [1], Fowler presents an optimistic approach to CI and does not talk about the problems that may arise. I will discuss some of these issues that I have observed during my placement.

The project must have some kind of infrastructure before applying CI. But what if the current project is being developed using an older project that didn’t use CI? Many companies (including the one I worked for) use legacy code when developing a new software product. This makes the process of achieving CI even longer and more unpredictable. The most effective solution is to use an incremental approach; start with less frequent builds and increase the frequency as everyone becomes more confident.

The larger the team, the increased overhead in maintaining a CI system. Because of the increased number of developers, the team I was a part of decided to have multiple component CI systems. The project tasks were split between several smaller teams who applied their own CI approach on their work. These sub-systems were used to build an overall system level CI which proved to be more efficient than if there was a single massive system from the beginning.

It is very important for the repository to contain everything necessary for a person to build anything. Test and install scripts, IDE configurations, documentation and many other things must be committed to the mainline especially if the code may be reused in the future. Also, artefacts from old builds can produce false results. Developers must clean the old artefacts before running a new build.

As I said, doing CI effectively involves frequent builds and commits from all the team members. Developers must commit every few hours so that bugs can be fixed quickly and the progress tracked efficiently. However, not all the members of a team have the same level of experience. Graduate students are hired throughout the year so it is very likely that they will end up working on a project that is already mature and applies CI. The solution is to provide systematic training and ensure that everyone has good test coding and build scripting skills.

The worst-case scenario is that people commit just before going out for lunch or before they leave work. This was proven to be a bad practice since it causes many integration errors. Frequent builds and commits throughout the day ensure that the bugs are found and fixed quickly.  This also helps increase the moral of the developers since they don’t need to delay lunch and can leave work when proposed.

It is important to differentiate between nightly and weekly scheduled builds and the integration builds. The scheduled builds are usually test builds that take a long time and run even if changes have not been committed. It is advised that developers do an integration build after every change to the mainline. This is because even if a build succeeds it does not mean that software product is working correctly. If later on a full integration build fails it will take longer to find and fix the bug.

Fowler says that builds must be fast but he is not talking about the quality of the final code. If developers rush into building and committing their work it is likely they will not meet the company’s coding standards. It is better if they take their time and make sure that they produce good quality code and save time later on refactoring.

Eric Minick makes a good point in his article [2] where he suggests that Fowler’s article is too focused on build. He says that Fowler should have expanded the scope of CI past build time by emphasising more on the importance of testing. Given my experience within a company I agree with Minick that tests are very important. Most of the employees were verification engineers and a wide variety of verification methods were used. A lot of time and effort was put into verifying the software product and bugs found from running tests were considered a great success. This is because finding bugs proves that the verification techniques are working effectively.

CI was very useful for this project since the customers intended to use the product to create their own. Using frequent integration and bug fixes, small releases could be made to the customers. This allowed them to start their own software projects earlier rather than wait for the final version. Moreover, if the project is late and the customers get impatient, build and bug reports can be sent to them. This way the company is able show the project’s progress and receive constructive feedback.

Communication between the teams working on the same project or between a team and the team leader is also a part of CI. The team I was part of had weekly meetings in which they were discussing the bug and build reports. The progress of each team, interactions between their work and the customer’s input and expectations were reviewed and examined.



Continuous Integration should be a part of each software development process irrespective to the subject of the project or the team size. Although it is a simple concept it is very easy to implement the CI concepts wrong and obtain poor results. Making the builds very fast or too frequent and committing the work at the end of the day are just a few of the bad practices of CI. However, if implemented correctly, CI is an essential part of a successful project.



[1] Martin Fowler, “Continuous Integration”, May 2006, accessed February 2014

[2] Eric Minick, “Continuous Integration: Was Fowler Wrong?”, July 2008, accessed February 2014

Architectural patterns for Mobile Application Development

1. Introduction

Mobile application development share common software design principles as desktop application development. However, typical mobile applications follow the mobile application lifecycle management process [1], [2] that differs from desktop applications.

Mobile applications often require more user interaction compared to its desktop counterpart, usually waiting for an action from the user (such as a button click) before responding to the user with an updated UI showing the requested information. We will discuss a software pattern that focusses on the interactive aspects of mobile applications as well as a more general high-level decomposition pattern and discuss their uses in mobile application development.

2. Model View Controller (MVC)

The Model View Controller (MVC) pattern [3], [4] is a very popular approach for the development of a mobile application. We observe that most mobile applications’ core operation is to retrieve data from a data store and update the user interface with the newly requested information based on the user’s inputs. The logical sense is to tie the user interface components with the data store components. However, since the user interface components are updated regularly to accommodate the changing user requirements and new technologies – more so than the data store components, we introduce extra coupling in our system. The aim of this pattern is to separate the components of user interface (View); core functionality and data (Model) and the response to user inputs (Controller).

2.1 MVC in the context of Android applications

I will first provide a brief overview of the components of the Android system. The main components [5] are:

  • Activity – represents a single user interface class. Activities are usually packaged together to form the UI components of the application.

  • Service – allow tasks to be executed in background threads (such as networking operations) without affecting UI components.

  • Content Provider – enable data to be stored within the application with the use of SQLite database or SharedPreferences (data stored in an XML file on the device).

  • Broadcast Receiver – responds to announcements from the system (such as low battery warning) and provides notifications to the user.


In my experience of developing Android applications in the SELP third year project and my final year project, my opinion is that the suitability of the MVC pattern depends on the context of the application in question.

My project is based on a tourism application consisting of: UI components (update a list of nearby points of interest and displaying these to the user); service components (location listener for tracking user location using GPS and detect changes, background running tasks to fetch data from other services); data components (for storing and retrieving user preferences); widget components (buttons, edit text, text views for handling user clicks and inputs).

The UI components is made up of a package of Activities that resemble the View component of the pattern where each Activity updates and modifies the UI throughout its lifecycle. The service and data components represent the Model component of the pattern in that it monitors the behaviour of the data and core application domain. It also handles requests from the View and Controller for information about its state and instructions for changing its state respectively. The widget components are similar to the Controller in that it waits for user inputs (such as a button click) then interprets those inputs and notifies the Model or View of the change.

In the high-level overview of my application, it seems that MVC patterns fits well with the Android ecosystem with each application component more or less mapping to the Model, View and Controller. However with closer inspection of the details, things are not so straightforward. An example is the Activity component that forms part of the application. Each Activity consists of a Java file and a corresponding XML layout file. We define the UI layout of the Activity in the XML file and implement the functionality and behaviour in the Java file (separation of user interface with application logic). When we use widget components in our Activity, we first have to define the widgets as XML elements in the layout file to instantiate the widget and its attributes. The handling of the behaviour of the widget in response to user actions is then implemented in the Java file. However, we often have to access the widget’s attributes from the XML layout while implementing its functionality and this violates the concept of separating the View from the Model/Controller in the MVC pattern.

A possible solution to this is to use an Observer pattern within MVC. We could make the Activity components (View) implement an Observer interface to receive updates and notifications of changes to the application logic (Model’s state). When a change occurs, the application logic notifies all its Activities (observers) of the state change. This eliminates the coupling between the Model and View.

Figure 2. Using Observer within MVC [4]

3. Layered Abstraction

The Layered Abstraction pattern [6] consists of a hierarchy of layers. At each layer, we have components that work together within the same level of abstraction, with the layer below providing functionality for the layer above.

The Android architecture [7] follows this Layered Abstraction pattern. It consists of four layers of abstraction with direct communication only between a layer and the layer directly above or below it:

  • Applications – this layer consists of a set of core applications as well as developed applications.

  • Application Framework – layer which contains the main components of the Android system (Activity, Service, Content Provider, Broadcast Receiver) as well as other system components.

  • Libraries – consists of core Android system libraries as well as a lightweight relational database management system – SQLite.

  • Linux Kernel – contains device drivers which provides communication with the device’s hardware.

Figure 3. Android system architecture [8]

I will now provide an example scenario from my tourism application that follows this software pattern. When a user uses the application to determine their current location, a background running task is executed from the Service component which sends a location request from Applications to the Application Framework layer. The location manager sees the request and provides periodic updates of the device’s geographical location (latitude, longitude coordinates) with the help of the core system libraries in the Libraries layer. The system libraries communicate with the WiFi and GPS device drivers in the Linux Kernel which interact with the device’s hardware to receive GPS signals. Once the signals are received the notifications are propagated back up the layers to the Application layer which updates the user with their location information.

4. Conclusion

In this blog post, I discussed the interactive MVC pattern and the high-level decomposition Layered Abstraction pattern and their relation with mobile application development.

In terms of the MVC pattern, I think for applications with large UI components it might be worthwhile following this pattern of design as the constant update and modifications of the user interface due to the rapidly changing nature of user requirements will result in less work maintaining the core business logic of the application.

With the Layered Abstraction pattern, since the Android system follows the abstraction layer architecture as discussed above, we can say that this pattern forms the foundation for all Android applications that makes request to services and receives notifications from them.











The New Web: The Tools That Will Change Software Development

When I think back of 2006, the year I added “Freelance Web Developer” to my resume, memories of a simpler and somehow more welcoming Internet come to my mind.

In 2006 one of the most critical design decisions that a web developer had to make was: “Should we target 1024×768 or 1280×800 displays?” The Mobile Web was mainly mentioned in newspaper articles telling the stories of unfortunate men who were to pay hundreds of pounds to their mobile carriers for accidentally pressing a mystical button with a tiny globe icon on their new Nokia.

The iPhone did not exist, neither did Android and it was still O.K. to create an entire website using Adobe Flash.

Don’t get me wrong though, this is not some nostalgic note of times past, neither am I trying to argue that we were happier to design a button with rounded corners consisting of 9 PNG images. Internet Explorer dominated the Internet with a market share of well over 60% and implementing a two-column layout that looks identical in IE6 and IE7 involved more lines of CSS hacks than lines of style definitions.

Fast-forward 8 years and we have transitioned in an entirely new epoch of the Web. Web design is responsive– it reacts “intelligently” to the user’s device and does not make any assumptions about the media it is reproduced on. Websites have turned into Web Apps and the users’ browsers do the majority of the heavy lifting instead of the server. New tools have emerged that manage the entire lifecycle of a web application from dependency management, through provisioning and testing, all the way to user profiling and immediate pushing of hot-fixes.

All of that has allowed software developers to utilize web technologies and build amazingly complex application using just HTML, CSS and JavaScript. In this article I will briefly introduce some of the exciting new tools available to developers and share my humble predictions about the future of the web and software engineering in the next couple of years.

Platform as a Service

Eight years after the launch of Amazon Web Services [AWS], the Infrastructure as a Service model is hardly a new concept for anyone involved in the field of software engineering. Platform as a Service [PaaS] is the logical continuation of the AWS model, but made a whole lot easier. Heroku  and OpenShift by Red Hat  are two excellent examples of the powerful change happening in the field. These providers allow developers to deploy cloud applications in a matter of minutes, giving them the power of elastic scalability, load balancing and continuous deployment. PaaS providers expose APIs and command line tools that make the release of a new application version as easy as doing git push paas_provider.

I have been using the free tier of Heroku for well over a year now and it has allowed me to ship application prototypes and publish hot-fixes in unparalleled times. Its big disadvantage is the price of production deployment compared to Amazon Web Services.

Arguably the future of PaaS is in the further development of technologies such as Docker  that essentially allows a team to host its own PaaS on any server environment they choose.

JavaScript for clients and servers 

NodeJS is one of the server-side technologies supported by all major PaaS providers and the rate of its expansion certainly hints at a bright future for JavaScript on servers.

Node is platform built on Chrome’s V8 JavaScript engine. It has been developed specifically for distributed real-time applications that operate with a lot of data. The power of NodeJS lies in its simplicity and low-level applicability – it is equally suited for creating game servers, chat applications or content management systems. In fact recently a member of the WordPress dev team raised nearly 8 times higher than his goal in a Kickstarter campaign for a blogging platform based on NodeJS.

The reason I am an advocate of JavaScript on the server is the reduced tension between front-end and back-end development. It is ideal for small projects where the developer does not need to switch languages and browse multiple documentation sources. But the real power of NodeJS emerges in large teams where, if the appropriate coding standards have been followed, a developer is no longer responsible of a single side of the coin, but instead works on an entire flow of business logic that may span across both client and server.

A notable companion of Node is ExpressJS. This is a web application framework that builds on top of Node adding services such as routing, user sessions, hooks to database engines and many other essential features for building dynamic websites.

Server-side applications

Ever wondered how Google made applications such as Gmail respond to user actions in real time without refreshing you browser? Here is a hint: they did not use PHP.

In fact with the advancement of JavaScript browser engines and the adoption of techniques such as AJAX, developers have been able to offload the task of rendering views from the server and assign it to the user’s browser. The event-driven nature of JavaScript, on the other hand, allows UI elements to respond and views to be swapped as soon as the underlying data model has changed.

There are a number of technologies that aid the development of similar applications and the main difference between those lies in the amount of assumptions that the given framework has done for the developer.

Backbone is arguably the most powerful and flexible client-side application framework to date. It leaves to the developer the duty to set up data binding between interface elements and data models, as well as to choose engines for templating and routing. It is ideal for cases when performance is of the highest priority and the developers are ready to make the majority of the design decisions.

Angular on the other hand is Google’s own interpretation of the future of the web. Apparently it was developed when a JavaScript engineer at the Silicon Valley giant decided he could cut 6 months of development down to a few weeks if he took the time to complete his free-time project. Now angular powers a number of Google applications and has been supported by an overwhelming amount of open-source projects.

Certainly technologies such as Angular, Backbone or any of the frameworks “benchmarked” at the TodoMVC are overkill for simple websites with a few pages. But for large-scale browser applications, something that is becoming increasingly common lately, where speed makes the difference between keeping and loosing a client, these technologies are simply a must.

A few final words

The web has entered a new era and I find it increasingly surprising when software developers using more “traditional” languages and tools, label development for the web as a job for beginners. The web has truly allowed us to be more efficient, to develop faster and have a bigger impact on our users. Some have even reached as far as to state that JavaScript is the new Assembly.

I believe that the time has come for computer scientists to embrace the change and start making more beautiful, accessible and future-proof applications using the new Web.

Version Control: Important for Individual Projects?


One of the first things we have learnt is to use version control with everything, especially if it is a big project. Using online repositories can put your mind at ease that your work is backed up but there are far greater advantages to using version control than that. Organizing through the iterations of software development is extremely important for many reasons. The merits of version control will be discussed however there may be times when these systems could cause some aggravation.

We shall see if some of its best features may not be useful to the individual programmer. Specific technologies will not be discussed but rather the general advantages and disadvantages of such a tool.



Version control refers to a repository of files, which usually stores the source code of a project. It is used to track and record every aspect of the development of software including who has made changes, why they have done so and to what the changes and additions refer to. The overarching purpose of this is to allow multiple users to work on the same project however where this repository is stored and who has access to it is up to the discretion of the owners of the software. The working copy is the most up-to date version of the software or the ‘head’ but previous history and iterations are saved and can be viewed as needed. There are many factors and options when considering which technology to choose since many exist and provide different features. They use different models to store and track changes so the appropriate technology must be chosen depending on the needs of the project.



There are numerous reasons why version control is used and highly recommended during a software engineering project.

As soon as you introduce more than one developer into the mix, this tool becomes essential to maintaining an organized structure. The team doesn’t even have to work from the same location at this point, as long as they have access to the repository and can communicate with each other, they can all work from the same source code. This also ensures that everyone is consistently up to date with the latest version of the software. These advantages do not apply for an individual developer.

Errors such as accidental overwriting or breaking the code are no longer such a hassle since you can always revert back to older versions where all the information is present and works. If the project had certain deadlines on deployment or on certain features this is also aided with version control. You can work on other aspects and improvements while still keeping a previous working version that you can adopt if needed. This feature is very useful even on an individual project and is a big plus in favor of using such technologies.

Keeping track of who did what can also be quite important when debugging/trying understand what is going on or when creating documentation. It also makes people accountable for the work that they have done. Again, this merit is not advantageous to the lone programmer.

Version control gives you the option to expand your project in the future and engage in possible collaborations with others. Even in smaller projects you can use it to keep happy and sane throughout the project so this is a big plus in favor of this tool.

Sometimes version control can be a pain and can cause some aggravation for those who are using it. This applies heavily when there are many people working on the same part of the code who want to commit both their changes with many conflicts in them. Merging your edits with someone else’s can be very difficult or they can break the code completely, unfortunately there is no way around this. When working alone, all of this irritation simply doesn’t exist.

Another point of stress includes having to learn how to use the tool and setting up the system for version control. This will take time and learning the commands and functions to use the system can be hard. You must use it correctly to avoid messing up the code, however once familiar it will become a lot easier to deal with.

If a third party controls your repository, this can also double up as a back up of your project, definitely advantageous to projects of all sizes.

Personal Experience

During a 3-month internship last summer (2013) I worked for a startup consisting of 4 developers in total. Each was responsible for their own piece of the project and never really touched anyone else’s code. Also, the team sat around the same table every day so communication was easy. We used version control and it was extremely useful for the project management, even though the team was small and never working on the same part of the software. Even though it caused some headaches and took effort to setup and configure, I do not think the project would have been as near of a success without it. This was especially important when one team member was working on a seperate branch; it meant that the rest of the team could easily continue development on an older version of their software.



It seems that version control is not completely necessary for the individual programmer since a lot of the reasons why this tool is so useful do not apply in this circumstance, and those that do are not essential. There are nevertheless very useful and will make life a lot easier.

`           I still use version control for all of my larger projects, not that I have yet needed to revisit previous versions of code or review the history, but more to keep the source code organized and backed-up, and keep myself happy whilst working. You do not need version control when working alone but it is highly recommended.

If I had to continue this line of discussion, I would perhaps try to figure out from the set of available tools in the current market, what offers the best features for the individual programmer?


[1] Clark, A. Tools for Software Projects. Lecture slides, University of Edinburgh. Feb 2014 [Online]. Available:


[2] Yeates, S. (2005). What Is Version Control? Why Is It Important For Due Diligence?. Available: Last accessed 4th Feb 2014.


[3] Nagele, C. (2013). Introduction to Version Control. Available: Last accessed 4th Feb 2014.


[4] Stansberry, G. (2008). 7 Version Control Systems Reviewed. Available: Last accessed 10th Feb 2014.


Some new ideas for successful software management

Do you think software project is boring? Try to view it from another perspective!

When talking about software management, many people may think it involves high technology management or disciplined engineering management. However, Walker Royce, the vice president of IBM’s Worldwide Rational Service Organization, has given a new idea that software project managers are much easier to succeed if they regard their project as a movie production other than an engineering production. I felt doubtful and curious when I first saw this idea. However, when I read through the article, I think it’s really an original and rational idea that could be applied to the modern software management. I will elaborate some important elements that are vital for successful software management in the following sections.

So what are the important elements for successful software management?

In conventional wisdom, software managers may have many requirements for the project and his team. However, it’s probably the most misused word in the industry. In a software project, you can rarely see something is unchangeable. Plans, people, funding, milestones, designs and tests are all the component of the project. However, all of them may be change and negotiated at any time. So, the word “requirement” is improper to define or judge a project. Furthermore, the performance of software products could be measured by users’ perceived value. So, economics performance can help to prove if the software is successful or not. It’s pretty similar with movie productions. We can evaluate a movie by observing the feedback of viewers and the profits. So, in today’s modern software management, it just likes a movie industry. The qualified architects can be regarded as directors, analyst can be regarded as scriptwriters, and software engineers can be regarded as actors and so on. Especially, good project managers just like good movie producers. Furthermore, we can describe the modern software management as a discipline of software economics rather than software engineering. The software managers should make their everyday decisions like movie producers that based on human factors, macro-economic trends, technology trends, market strength and so on. In order to deal with these subjective decisions, Walker Royce recommended “using a steering leadership that compromise active management involvement and frequent course correction”. In addition, he came up with four patterns for successful steering. I will introduce and give my opinions about them.

Scope management

Walker Royce thinks that solutions and user specifications are evolved from each other. Because “requirement” is regard as a misused word which is mentioned earlier, he prefers to use the word “specification” instead. The first form of specification is the vision statement or user need, which could help to deal with the contract between the project development group and user or customer. The developer should use specific and formal format which might involve models or texts to make users understand the information. The second form of specification is not really similar with requirements. Walker Royce called them evaluation criteria. They are temporary steering targets not only from the vision statement but also from various other sources such as risk management analysis; architectural considerations; constraints of implementations and so on. I think Walker Royce really gave a proper revision for “requirements” in traditional software management. He has noted that the requirements are changeable, they receives a great deal of scrutiny because it always influences the contract between developer and users. Besides, I think he also noted the importance of “interim”, which could provide a better skeleton for early testing and give more accurate information for both developer and users especially for a risk management plan.

Process rigor

For most project managers, they would approve that the processes might be rigorous when the teams are distributed or the project is fall behind the lifecycle phases and so on. However, Walker Royce comes up with a distinctive idea of successful software development process that earlier phases center on realizing demonstrable functionality and later phases focus on robustness and performance of the product. Besides, the process rigor has equally important affect on teams. I really agree with his idea. The software development process is very similar with our assignment. Processors need to balance the various students and give proper deadline so that most of the student could hand in assignments with their maximum abilities. In addition, I think Walker Royce’s arrangement for the lifecycle phase is well-designed. It could help to give an appropriate plan in case wasting time or working too much in some lifecycle phases. Today, an improper focus on process rigor is the basic reason for software projects fail.

Process honesty

In the traditional development process, there are tremendous reasons may cause the developers and users don’t trust each other. However, most people may not concentrate on it although it is a very important factor during the process. Walker Royce finds this and he thinks trust is essential to steering and to keep a balance on users, developers and plans. I think trust is inconspicuous but very important. His idea recommends us pay more attention to a functional and usable product rather details of contract.

Quality control

Walker Royce considered that testing and testers become the first vital component in the progress. Every team should build test cases. The analysis team would find the peak data load or critical control scenario that lead to extreme cases. The design team would come up with a competitive model. The test team would build test cases and capture its response. I think testing is the key point among a project. We can build test and find the worst case. Besides, when testing, we can improve our project’s robustness. It can be simplified as programming, we need to consider as much conditions as we can in case the program may not succeed. To sum up, I think testing is indispensable.


As can be seen from above, good project manager is just like a good movie producer that not only develops good products but also helps to guide the less experienced team members. Furthermore, I think the steering leadership style raised by Walker Royce is an original and brilliant style for successful software management in modern. Not only can we create satisfied products, but also get economics benefits. In addition, I think Walker Royce really gives me a wider scope for software project. It could also be regarded as the construction of building and so on. He evokes me to think of the software project management from various perspectives, and it will not boring and hard when talking about software project any more. I’ll apply these new ideas to my future career.


1. Walker Royce, Successful Software Management Style: Steering and Balance, 2004

2. P. Graham, Hackers and Painters: Big Ideas from the Computer Age, O’Reilly, 2004.

3. Standish Group International, CHAOS Chronicles, 2004.

4. W.E. Royce, Software Project Management: A Unified Framework, Addison-Wesley Longman, 1998.

5. M. Cantor, Software Leadership, Addison-Wesley, 2002.

6. J. Marasco, The Software Development Edge: Essays on Managing Successful Projects, Addison-Wesley, 2005.

7. P. Kroll and P. Kruchten, The Rational Unified Process Made Easy: A Practitioner’s Guide, Addison-Wesley Longman, 2003.

Two types of Estimation in Software Development

In this article I will identify and distinguish two different types of estimation in large-scale software development. Also I will discuss the techniques to improve the accuracy of estimation for each of them. I will use some examples and analogy to illustrate and prove my points and hopefully every reader can easily understand it and learn something.

Estimation is hard!

There are some facts about estimation that few people dispute them. Usually the estimation work is done at the beginning of the project with poor requirement specification by hand. Some project estimations are even performed only with a rough idea. It is determined by the nature of the project, most of the time it is more like a demand. For example, think about the time that cloud storage services were not that popular yet. There are several companies can expand in this market and could earn massive profits. Now the companies have decided to develop a running project as quickly as possible or the market share will be obtained by the rivals and then put a deadline on the first release, say three months. In this case, three month is just a demand rather than a completely reasonable plan. Even though this estimation is not necessarily bad because anyway it can be achieved by modifying the requirements accordingly[1], but it is definitely not a good estimation because that was coming from the customer requirement(strategy of the company) rather than from the project itself[2]. Early and continuous release can perform very well with small projects but it may cause refactoring and other issues when it comes to large-scale projects which will make it more difficult to estimate. It is fairly easy to estimate and control when the project is small but it becomes more and more difficult when it scales up. Till here, we have reached the conclusion that estimation in large-scale software development management is hard.

Estimation is not always hard!

If you are familiar with Agile development methodology, then you’ll know the entire development process will be divided into small iterations which are often one to three weeks[6]. There is estimation involved in each iteration. Each iteration will be given a theme and include tasks picked from the task backlog which are considered to fit the developer’s capability in terms of time. Imagine a developer team of 10 people. For a two week iteration, the total time capacity of the team will be 10*8*5*2 = 800 hours(8 working hours a day, 5 working days a week). That means tasks worth total number of 800 hours work can be picked and put into an iteration and that requires an estimation of each task. In the beginning of each iteration, there is a group meeting in which those estimations will be made. Now, the estimation here is way different from the one mentioned earlier happening in the beginning of entire project. Each iteration can be viewed as a small portion of the whole development process and each task is even a smaller portion within the iteration. That is to say a task(which we’re trying to estimate how much time it would need to be finished) is very specific and small compared to the entire project. Small fraction means that it does not have much potential issues which may cause delay. In other words there’s little interference to be considered and easy to estimate. Also these small pieces of work are usually measured by hours and any mistakes in estimation would not make too much differences. Two hours variation is nothing compared to two months. Also it is more flexible when we are talking about hours instead of months. For example, a developer spent two more hours on a task than it was originally estimated. He/She can easily catch up on other tasks. Based on my work experience, a Scrum team of about 20 people can produce fairly accurate estimations on tasks.

Ways to improve the accuracy of estimation

Now two different types of estimation in large-scale software development management have been identified. In order to improve the accuracy of estimation, different techniques have been developed respectively for them. COCOMO and poker playing are used as examples here and we can find out that they are totally different techniques[5]. The techniques for improving estimation accuracy of entire project/components/modules are usually involved with lots of mathematical and statistical equations. COCOMO is a mathematical equation that can be fit to measurements of effort. The simplest form of COCOMO consist of as many as 4 factors including the complexity factor, measure of product size, exponent and a multiplier to account for project stages(Details of COCOMO will not be given in this article because we’re only interesting in the comparison of the different techniques of how they would work). There are other methods like Standard Component Estimating but similarly using mathematical techniques to make the estimations more accurate.

Now let us have a look at what people usually do for the estimations for small tasks. Poker game! It looks informal and less complicated and much more funny than the COCOMO even by the name. And it truly is. The poker game is just a group of people having cards in their hands and giving their estimations to each task on the list simultaneously and anonymously. When there’s an objection then people exchange their opinions and re-play until there is an agreement. Simple like that. It is very easy to apply and useful. Again because the task is small so it is easy to estimate and any experienced developers can give accurate estimations on them. Compared to COCOMO, it is more subjective because the estimation is made based on the developer’s experience.


In this article we discussed two different types of estimation in software development. One is early effort estimation of the project and other one is the estimation of small tasks with each iteration of the entire development process. Though both of them estimate the effort, timeframe and cost involved in delivering a project[4], there is a great disparity in the importance and level of difficulty. Estimate gets easier to make when it proceeds to the end of the project. Early effort estimation are made in the beginning of the software lifecycle which means the wrong time, and usually by wrong people for wrong reasons. No doubt that it will be very hard. The large-scale software management is risk management[8]. From the entire project’s point of view, there are lots of unknowns and risks. So the estimation would be used to give a big picture of it and steering the development process. Different from this, estimation for small tasks within each iteration has a very clear specification and know exactly what to be done. It is just a matter of resource allocation(management). That is assigning the right person for the right task(For example, one developer who is familiar with the component/modular involved in a specific task should spend much less time than those never worked on that component before).

Let’s finish this article by an analogy with hiking[7].So the project is to hike on the coast from San Francisco to Los Angeles. We should start with some planning like draw the route on the map and calculate the distance. Say it is about 400 miles long, if we can walk 4 miles per hour for 10 hours per day. It will be accomplished in 10 days. Now, the 10 days estimation is the outcome of early effort estimation. OK we are packed up and ready to go. On the first day, we are supposed to get past the Half Moon Bay. Before that, we have to get away from the city. So here’s the plan: 3 hours walk from home to the coast and 7 hours of walk along coast till we get past the Half Moon Bay. Getting to the coast from home and past the Half Moon Bay can be reviewed as two tasks in the first iteration(day one) and 3 hours and 7 hours are the estimations for them respectively.



[1] Allan Clark, Software Architecture Process and Management lecture, University of Edinburgh.

[2] Get Ready for Agile Methods, with Care.

[3] Estimation is evil.

[4] Dynamics of effort estimation.

[5] Cost models for future software life cycle processes: COCOMO 2.0 Boehm, B., Clark, B., Horowitz, E., Madachy, R., Shelby, R., and Westland, C., Annals of Software Engineering, 1995

[6] Manifesto for Agile Software Development.

[7] Estimation Analogy with Hiking.

[8] Large-Scale Project Management Is Risk Management. R.N. Charette. IEEE Software, July 1996.

[9] Combining Estimates with Planning Poker–An Empirical Study.

A Review of Two Software Risk Management Methods

Software risk management is necessary

Currently, information industry is growing quite fast. Not only the number of the technologies but also the complexity of the user requirement of software development is increasing. As a result, software companies need to try their best to improve the product quality as well as reduce the development cost. Hence, only when software risks are managed and controlled well can the companies run their business successfully.

In the process of developing a software, when an unsatisfied outcome that can cause negative impacts has a certain possibility to happen, it can be called as a risk.[1] To handle these risks, a great amount of approaches had been developed. In this article, two of the popular ones will be briefly introduced and compared– Boehm’s Risk Management Method and SEI’s Risk Management Method.

Two popular methods

* Boehm’s risk management  method[6]

Boehm, a famous software engineer, contributed a lot in the area of software engineering. Boehm’s risk management methods is also a classical one which can give developers a lot of graceful ideas.


As Figure 1 shows, there are 2 primary phases in Boehm’s method, risk assessment and risk control. In risk assessment, there are three sub-steps: risk identification, risk analysis, and risk prioritization. In risk control, there are also three sub-steps:risk-management planning, risk resolution and risk monitoring. Now a brief explanation for each of the sub-step will be given below:

➤ Risk identification: Produces a list of the risk items according to the specific project. One of the major techniques for this is Boehm’s top-10 software risk items checklist contains the top-10 risk items produced by Boehm in terms of his research, and the management techniques from Boehm for each risk item.

➤ Risk analysis: Makes assessments of the relevant loss and the possibility of the unsatisfied outcome, in terms of each of the risk item listed in the risk identification phase. Besides, assesses the compound risks when all the risk items appear in the same project.

➤ Risk prioritization: Produces a ranked ordering of the risk items. One of the major techniques is calculating the “risk exposure” quantity by multiplying the relevant loss and the possibility of the unsatisfied outcome of each risk item, then make a combined consideration of the three values, i.e., the risk exposure quantity, the possibility of the unsatisfied outcome, and the relevant loss of the outcome.

➤ Risk-management planning: Provides a plan for each risk item, as well as an overall plan for the whole project. A useful tool here is also Boehm’s top-10 software risk items checklist. Plans of numbers of specific risk items can be made according to the checklist without wasting too much time and effort. This phase makes a preparation for the risk control process.

➤ Risk resolution: Implements all the elements in the plan to provide a suitable situation for eliminating or resolving the risk items.

➤ Risk monitoring: Offers the whole project a tracking, in order to ensure the risk management process is under control.

* SEI’s risk management method[2]

Software Engineering Institute(SEI), is a federal research center for software engineering funded by the US Air Force, to improve software system quality, safety, reliability, and so on.

Figure 2 presents the SEI’s Software Management Model, known as SEI-SRM Model, consisting of six parts: identify, analyze, plan, track, control, and communicate.


In the phases of identifying risks, analyzing risks, planning and part of communication, the Software Risk Evaluation (SRE) [2] methodology acts as an important role. SRE Team consists of numbers of software engineers. The duty of SRE Team is analyzing relevant issues and document the result according to the requirement of the project. [2] SRE Team also offers helps when there are unexpected situations.

➤ Identify: Each member of the SRE Team identifies the risk items according to a taxonomy which lists all the potential risk areas, then documents them on the Statement of Risk, which is part of the Risk Management Form.

➤ Analyze: This phase is also supported by SRE Team. Each risk item identified in the first phase will be analysed in terms of its possibility of occurrence and the relevant loss, etc. After that, items will be prioritized and set as different Risk Levels. Lists of risk items with their Risk Levels and an updated Risk Management Forms are produced.

➤ Plan: SRE Team members make a combined consideration of both individual risk items and the whole project, then produce a Risk Management Plan. What’s more, documentations about how to make sure the risks being handled are also provided by SRE Team.

➤ Track: The status of the risk are always being monitored. Whenever the threshold in the relevant documentation is exceeded, actions should be taken to mitigate the risk.

➤ Control: In the Risk Management Plan, there might be deviations. Risk control acts as a role to manage risk plans and make corrections to the deviations, so that the whole process can be improved.

➤ Communicate: Communication lies at the center part of the SEI-SRM model, connected with every other parts. In the whole software risk management process, communication is also significant. Whenever there is information being collected, it should be passed to others for integration so that personnel can share information together, work in the most effective way and come up with the best results. Communication is also necessary between different organizational levels, such as the developer, the customer, and the user. Without an effective communication, no successful risk management process can be implemented.

What are the merits and drawbacks of them?

After the introduction to each of the two risk management methods, a discussion of them will be given below.

Boehm’s method has a high reputation among the software risk management area. The top-10 software risk checklist is a useful tool in many phase of the whole process, saving personnel, time and efforts.[3] The concept of “risk exposure” is also a graceful estimation technique for the criticality of the risk item. A good many investigators have been inspired by Boehm’s idea for further researches. However, several drawbacks cannot be ignored. The top-10 list is just a summary of risk items by integrating relevant information. It lacks convincing articles about its fundamental theories, original data, and induction methods. As time goes by, it is changing continuously, and of course needs to be modified continuously. Moreover, the listed risk items can also be changed according to different risk management methods, so it does not fit all the situations. Thus, the top-10 list needs to be improved and expanded although it has certain universality and practicality. Besides, the estimation of both the possibility of the occurrence of the risk and the relevant loss cannot be one hundred percent accurate. As a result,  the “risk exposure” quantity itself is a risk item.[4]

With the participation of SRE Team, relevant discussion can be made whenever and wherever needed during the risk identification, analysis, and planning process, making the information collection and integration more graceful. This increases the reliability and the efficiency of the risk management process. This works even better when the environment is well planned and the whole process is well managed.[5] However, it may take more time for all the SRE Team members to reach a final agreement in one case. If something went wrong in the communication phase, the situation will easily become a disaster. Furthermore, to organize and manage such a large team increases the expense of the whole risk management process.


This article introduction and a comparison of Boehm’s software risk management method and SEI’s risk management method. Boehm’s software risk management method gives basic techniques and tools for risk management, as well as a large amount of ideas for further investigations. SEI’s software risk management method provides a continuous process for management with the support of SRE Team and successful communication. Although both of them are of high reputation, there are drawbacks need to be improved. As far as we concerned, further researches should focus on the accuracy of data collection and the efficiency of data analysis, as well as the methods to save expense and human labor.


[1] C. J. Alberts and A. J. Dorofee, “Risk management framework,” tech. rep., DTIC Document, 2010.

[2] Y. B. et al, “Software risk management: A practical guide,” 2000.

[3] M. Keil, P. E. Cule, K. Lyytinen, and R. C. Schmidt, “A framework for identifying

software project risks,” Communications of the ACM, vol. 41, no. 11,

pp. 76–83, 1998.

[4] K. Lyytinen, L. Mathiassen, and J. Ropponen, “Attention shaping and

software risk–a categorical analysis of four classical risk management approaches,”

Information Systems Research, vol. 9, no. 3, pp. 233–255, 1998.

[5] R. C. Williams, G. J. Pandelios, and S. G. Behrens, “Sre method description

(version 2.0) & sre team members notebook (version 2.0),” 1999.

[6] B. W. Boehm, “Software risk management: principles and practices,” Software,

IEEE, vol. 8, no. 1, pp. 32–41, 1991.

How Can We Strive for Simplicity when Everything is Complicated?

It Started Out With a K.I.S.S.

You may be familiar with the phrase: “Keep it simple, stupid.”

Software development is a field centred around deliverables and value.
There are rarely rewards for the most ingenious solution — save perhaps a wholesome, academic pat-on-the-back.

The size of encountered problems and their required solutions is continuing to grow. This is a by-product of the human desire to strive for bigger and better. Often the solution is so vast that a single skilled worker cannot produce it. Such endeavours earn the title of large software projects.

Once the task at hand is too much for a single entity, the project’s design process must span the unavoidable hardware gap present between distinct human beings. Here, the majority of code-spewing aficionados perform much worse than expected. Obviously this issue stems from humanity’s concept transmission protocol being neither lossless nor reliable.

When utilising the increased throughput of a multi-person team, code evaluation becomes subjective. A member’s software module that ticks all the objective boxes: efficiency, functionality, reliability, and using-spaces-not-tabs, may cause bottlenecks within the development pipeline if any of the rest of the group cannot understand completely what the unit does.

It is for this reason that we are often reminded to keep software components simple. Is this as trivial as the description implies? In the rest of this article, I will investigate whether simplicity is a concept that can be agreed upon. Ironically, simplicity appears to be yet another concept sometimes lost-in-translation and misunderstood during software design or evaluation.

Simple: How do?

What does simplicity mean in the context of software development? A common interpretation is to consider the plethora of programming languages available to construct a solution from.

Here [1], is a diagram detailing the perceived complexity, measured as the number of distinct ‘concepts’ present within several language’s design. It suggests that the complexity of C++ is far higher than that of the ‘competing’ languages: Ruby and CoffeeScript — due to the size of its feature-set.

I agree that C++ has a reputation for being complicated in nature, with its standards-commitee forever dreaming up new ways for you to blow your foot off [2]. Yet, I do not agree that this method of judging complexity is reliable.

As a counter-example, consider the feature set of the C programming language.

C has by far the fewest language features of today’s widely-used programming languages, but would anyone go as far as saying that it is a shining beacon of simplicity? Should teams chasing concept-clarity write upcoming features solely in a systems language from 1969?

I am arguing neither for or against the C programming language, as I have experienced it as both “simplistically elegant” and “overly cumbersome” across past and current projects.

Instead, I argue that the complexity introduced to any implementations of a given feature stems from the amount of book-keeping that anyone understanding a single module must do: The quantity of interleaving components that must be understood and remembered before contributors can describe the behaviour of the system as a whole.



Enough Space to Swing a Function Call.

Paul Graham presented the idea of using the count of distinct runtime components requiring consideration, as a metric for code size, in his essay: “Succinctness is Power” [3]. He argues, championing his beloved LISP over Python, that the latter’s quest for explicitly readability does not necessarily produce a software component that is easier to understand.

“What readability-per-line does mean, to the user encountering the language for the first time, is that source code will look unthreatening. […] It’s isomorphic to the very successful technique of letting people pay in instalments. Instead of frightening them with a high upfront price, you tell them the low monthly payment.”

This quote is a slight sidetrack from the point. It is being used for the purpose of claiming that one language is superior to another, something this article does not attempt. Yet, Graham continues and suggests:

“Instalment plans are a net lose for the buyer […] mere readability-per-line probably is for the programmer. The buyer is going to make a lot of those low, low payments; and the programmer is going to read a lot of those individually readable lines.”

Here, we can draw the conclusion that, assuming we need both reading comprehension and memory capacity for processing a line of source-code, language-concept scarcity and single-line simplicity is not necessarily proportional to the mental taxation involved when understanding a software module.

It is documented [4], that an average human has difficulty storing greater than “seven plus or minus two” differing items in short-term memory. With this limit in place, any block of code with a higher number of interacting sub-systems may prove difficult to understand cohesively.

If this is the case, how can modules be structured to aid comprehensibility and interpretation?



Curiosity Confused the Cat.

There is a solution to information-overload regarding the workings of a unit. Abstract away the implementation of modules via the usage of clear interfaces.

An interface is a strict set of entry points to the functionality of a module. An ideal understandable interface is one that is well-documented and a provides a suitable modelling abstraction. Given this, a programmer does not need to worry about the subcomponents that are performing any requested tasks. Instead, they must only maintain the code required to process communication to and from the module.

Blocks of code that perform a common set of tasks should be encapsulated before approaching critical levels of memory-complexity. By presenting only required interfaces to other disjoint blocks, the concept-count at any point can be contained below harmful levels.

A well documented API is not significantly harder to understand than a basic operator, as long as it known what should go in and how this maps to what comes out. Building from interfaces yields greater potential computational outcomes given a tight concept density budget.

Simplicity Does Not Mean Sacrificing Power.

The most important feature of a good interface is well-defined boundaries, its inputs and outputs. This does not mean that the work undertaken by the interface must be trivial. It is often better to have an interface performing an action that is complicated enough to require time set aside to understand, than have many interfaces perform separate parts of a larger transformation. Understanding the applications of a powerful abstraction can make a module’s intention far clearer.

A testament to this is the Haskell language’s ability to reduce many complicated computations into a simple mapping between abstract data types. Once the domain of the problem is understood, it becomes clear which functional primitives will provide a intuitive solution. Often, newcomers to the language complain that the language is difficult to comprehend. I feel that this is often due to a wish for ‘quick fix’. Many are reluctant to invest the upfront cost of studying the task’s domain — despite the fact that would provide a net-reduction to total effort.

I believe the ease of understanding the symbolic representation of a solution an unreliable indicator of true complexity.
This viewpoint is presented, relating to many programmer’s false studying economies, again in Graham’s “Succinctness is Power”[3]:

“If you’re used to reading novels and newspaper articles, your first experience of reading a math paper can be dismaying. It could take half an hour to read a single page. And yet, I am pretty sure that the notation is not the problem, even though it may feel like it is. The math paper is hard to read because the ideas are hard. If you expressed the same ideas in prose (as mathematicians had to do before they evolved succinct notations), they wouldn’t be any easier to read, because the paper would grow to the size of a book.”

By producing interacting software components that map to the problem domain as if they were operators, a team — or even a solo programmer — can utilise a domain-specific set of functions or services tailored to their needs.


In this article I have drawn attention to the most significant factor limiting the scalability of software teams, communication of intent and interconnection of distinct contributions.

The points raised do not attempt to prescribe a catch-all solution to the problem. Instead, they attempt to highlight a common misconception when judging module complexity during review.
I have provided an example of how teams can present subcomponents to avoid code bloat for the sake of ‘readability’. Different teams will find some techniques work better than others when partitioning work between members.

Embrace the abstractions of others. By investing the time to understand their contributions, teams can efficiently divide large problems at the conceptual level.
As a by-product, less work must be undertaken in restructuring the problem and the intent of the program is more clearly presented.

We are already standing on the shoulders of interfaces and abstractions, what harm can a few more do?

Developers and testers: friends or foes? Using fuzzy set theory to decide on the correct ratio of developers to testers in agile teams

1. Introduction


Developer and tester are two essential roles in the development of large-scale and long-term software. In the past few years, there are a lot of discussion of developers and testers. These discussion reflect that software industry develop very fast and the importance of these two roles. However, fight and cooperation never stop between developers and testers in the real world.  In this article, we will talk about developers’ and testers’ work, and how to decide on the correct ratio of developers to testers in agile teams.


2. What a developer’s and a tester’s day really like?


Everyone has their own impression of these two roles in their mind according to their experience. Even talking about the same role, it usually differ because of the size of the company which they work for, the tasks they should finish and so on.


2.1 What a developer looks like?


There is no simple answer to describe a developer’s life. It depends on what levels you are and the environment of you work (the size of the company you work for, academia vs Industry and so on). Talking about different levels of a developer, there is an interesting article talking about “eight levels of programmers” [1] . This may give you an impression of different developers. In this article, we will focus on the average developers in industrial companies.


2.2 What a tester looks like

I am going to give you a brief description of testers based on the experience of my friend who work as tester in his real life.

I have a friend who work as Software Development Engineer in Test in Google. When asking the first impression of his work, he said it is very cool and “luxury”.

Talking about cool, he has opportunity to use the most advanced technologies in Google, such as Google Glass. He thinks his job is “luxury” because of his work environment. He has two advanced computers in his office. He has two 21-inch LCD monitor, one is for debugging and the other is for displaying the interface of product. If your task is testing mobile phone, congratulations! You will have many latest mobile phones and tablets from different companies for your testing, and these can occupy all the space in your table if you want. He thinks these devices help him improving the efficiency of his work, taking into account a variety of complex configurations and simulating customer environments when using their products.


Someone always ask him that as a tester, you do not need to write codes, right? His answer is: of course I need to write code. He used to test thousands of use cases for a module, and it is impossible to finish the testing by hand before the deadline. He need to write a program for testing automatically.


2.3 Good management of developers and testers


Good management of developers and testers in the development of large-scale and long-term software is like manufacturing good pair of spear and shield. Testing is spear and developing is shield. If we know the strengths and weaknesses of spears and shields in the early stage of manufacture, we can make the weaknesses become strengths.

figure 1: figure from [6]

3 How to decide on the correct ratio of developers to testers in an agile team


There is a long-standing problem in the software development world: what is the reasonable ratio of developers to testers in an agile team? In the real world, the developer to tester ratios range from 1:1.5 to 10:1, including organizations, such as Microsoft, which have ratios that are 1:1 [3]. You can see that if you have an agile team to develop a project, you cannot just choose the ratios from other companies. What you should do is analyze your own situation and think about what ratio is best for your team. However, the question is: what criterias you need to use to analyze your situation?


3.1 Johanna Rothman’s theory


Johanna Rothman gives us an answer.[2] He believes that you need to consider:


  1. Product(the requirements, product size, and complexity of the product)

  2. Your project and its process (how your organization develops products, and your customers’ tolerance for defects and ship delays)

  3. Your people (development and test staff’s abilities and responsibilities) [2]


This is the general aspects you need to consider of your product. Furthermore, he gives us a table to evaluate  three different projects as follows:

figure 2: Contrast Process and Project Attributes[2]


We think this is a very useful table with detailed criterias to evaluate a project, and it gives us important information to decide on the Correct Ratio of Developers to Testers in agile teams. In this table, Johanna uses ü to describe a certain company has the issue or not. For example, LineChecker has to define and inspect the product architecture,  but BussyApp and DataCrunch do not have to.  He believes every company will get a score as a result according to their answers of this table, which decide their ratio of developers to testers in their agile teams.


However, we believe that although the criterias Johanna provided are very reasonable, situation in the real world are more complex. You cannot easily say that a project has or has not a certain criteria, such as low customer tolerance for ship delay. The real world situation is that our answer is not just yes or no, we have different levels of our answer, such as: very positive, positive, moderate, negative and very negative. To make the result more reliable, we will use a theory called fuzzy set theory.


3.2 What is fuzzy set theory?


Fuzzy sets [4] were introduced simultaneously by Lotfi A.Zadeh and Dieter Klaua in 1965. What Zadeh proposed is very much a paradigm shift that first gained acceptance in the Far East and its successful application has ensured its adoption around the world. At the beginning of twenty –first century, based on the fuzzy set theory, variable fuzzy set theory [5] is proposed by professor Chen. With the development of fuzzy set theory, it is meaningful to introduce fuzzy set concept, models and approach into data analysis of complex situation.Fuzzy set theory is an important tool in mathematical modelling, which allows for the explicit consideration of professional expertise and judgment. It will be necessary to analyze the mutual relationship between fuzzy measures and their applications. Based on the main concepts underneath fuzzy set theory, we can make the ratio of developers to testers in agile teams more reasonable.


3.3 How to use fuzzy set theory to decide correct ratio of developers to testers?


Since the data collected from Johanna’s criterias are not in a perfect quality, using fuzzy set theory are capable of representing uncertain, non-exact, diverse and inaccurate data or information. We do not want to use many fancy formulas of fuzzy set theory to scare away our readers, so we try to explain the use of fuzzy set theory in this situation as simply and clearly as possible. We redesign the table of criterias which presented be fore as follows:

figure 3: table for evaluate your own project


You can see from the table above that for each criteria, you can have five choices: completely agree, agree, moderate, disagree and completely disagree. Each option has its corresponding score. After using this table to evaluate your project, you will get a much reasonable result compare with the old version(just yes or no answer).


We will make it clear that this ratio is not stable. It can be changed according to the performance assessment. You can add different criteria to evaluate your developers and testers.


Maybe someday in the future, testers and developers will become one role, and there is no obvious distinction but each person’s tasks will be different.


4. Conclusion

In this article, we talked about the developers and testers in the large-scale and long-term software developing team. We provide a new idea of using fuzzy set theory to decide on the correct ratio of developers to testers in agile teams. To explain how to use fuzzy set theory, we showed a example of table including different criteria to evaluate readers’ project.


[1] The Eight Levels of Programmers, April 3, 2009 Jeff Atwood

[2] Johanna Rothman on Jan 1, 2000 in Articles

[3] Cusamano, Michael A. and Richard W. Selby, Microsoft Secrets, Simon and Schuster, Inc., New York, 1995.

[4] Zadeh. Information and Control. 1965.

[5] Chen, Shouyu. philosophical basis of variable fuzzy set theory. s.l. : The Journal of Dalian University of Technology , 2005. 53-57.

[6] Stock Photo – Old shield with sword isolated over white

Does Waterfall deserve its bad press?

In recent years, there has been a tendency to equate the Waterfall methodology with ‘evil’ and the Agile variants as ‘good’.  Having worked on successful projects under Waterfall (and Agile for that matter) but also some Waterfall projects that failed spectacularly, I would argue that Waterfall still has its place in modern software development.  This post will make the case that disregarding Waterfall as an option for future projects is potentially setting more software projects up for failure than need be the case.

But wait, I’ve heard terrible things about Waterfall

There can be no disputing that Waterfall is not a sensible choice of methodology for all software projects.  It can be rigid, dogmatic and, in many cases, can lead to the development being delivered no longer being what is required.  Waterfall can make changing something already done extremely expensive and time-consuming.  It is effectively useless if the client or user is not clear on what exactly it is that they want.  Waterfall is also not suitable for projects where development needs to start quickly or where the intention is to release incremental improvements to get benefits soon.  However, for the right project Waterfall can provide a stable and sensible framework for the project’s management and execution.

So, what is it good for?

Some might say, “Absolutely nothing”.  However, they are mistaken.  Waterfall projects generally follow the same pattern of linear phases – Requirements definition, Design, Development, Testing and Implementation.  This linear and well-defined structure makes Waterfall a relatively easy methodology to implement.  The discrete phases also give several advantages for the right project.  From a project management point of view, the phases make it easier to provide more accurate estimation of timescales and budgets (although this is not fool-proof by any means).  With the bulk of the research and analysis completed in advance to define the requirements, it allows the project manager (and developer) to estimate the time required to develop and test each requirement more accurately.  This, in turn, can provide more reliable milestone and release dates.

The phases, and the output produced at the end of each phase, also provide natural points and evidence for reflection and progress measurement of the project.  These milestones allow the manager to compare the current situation to that planned and have potential slippage highlighted, and remedial action taken, as soon as possible.

The Waterfall method also allows a team to cope more effectively with resourcing issues such as a team member leaving the company or moving to another project.  This is a common risk for teams within large companies.  These companies tend to have several projects/clients at the same time and so resources can be regularly reallocated to other projects, depending on the current priorities.  As a result of Waterfall’s insistence on documenting each stage of the process and the project knowledge (e.g., Business Requirements Document, System Design Document), it is easier for a new developer (or analyst, architect or testing for that matter) to pick up work that has been left by a departing team member as the knowledge is retained within the team.  Within teams, Waterfall also means that it is easier to accommodate specialists or inexperience than some methodologies that demand that team members are knowledgable on all aspects of the development.  Under Waterfall, team members are generally responsible for one area, such as requirements, user interface or testing.

Finally, Waterfall is one of the most effective methodologies for distributed teams.  As a result of the documentation produced, the defined phases and individual responsibility for tasks, the necessity for continual communication within the team is reduced significantly.

The model also provides advantages to the client or user.  Firstly, the upfront analysis phases encourage projects to define a clear plan and vision prior to development.  This helps ensure that the focus is on the right areas and that the architecture is right before development starts. A further consequence of this focus on defining requirements and system design upfront is that it can help with the quality of the development because of the time spent analysing the development and any potential risks.

Waterfall can also be helpful to clients because they are not required to provide resources or staff throughout the project as in Agile.  Under Waterfall, before testing and implementation, the project team only needs access to clients/users during the early stages of the project and at the defined milestones.  This is relevant as many clients are reluctant to contract a project team to develop software, only to provide the team with the client’s own staff, thereby increasing the cost of the project to the client.  There is also the relative security of potentially more accurate budget and time estimates.  Many clients are reluctant to commit to (and assume the risk of) projects where accurate estimates cannot be given in advance and the risk of cost overrun is left open.

So, what type of projects are right for Waterfall?

Most obviously, projects where the requirements are stable and unlikely to change in any meaningful way are good candidates for Waterfall.  One example of this may be a development being carried out to ensure a company can remain compliant with new legislation.  In this case, the legislation and resulting requirements are likely to be set in stone.  The up-front analysis and design also makes Waterfall an option for projects that are large and complex.  There is a risk with some other methodologies that the ‘bigger picture’, particularly if complex, gets lost in amongst the focus on requirements that can be delivered in iterative phases.  Finally, Waterfall is also a natural option for projects to develop critical systems.  Critical systems often require each step of the project to be reviewed, analysed and/or approved by management or client experts.  Waterfall’s phases and corresponding output provide easy milestones for these actions to be carried out.

This post is not arguing that Waterfall is a panacea for all software projects.  It is evidently not.  As discussed, the model has numerous flaws and, for the wrong project, can prove disastrous.  However, Waterfall remains a relevant project methodology in today’s environment.  The current trend of dismissing it as an option for software projects may lead to more software project failures than would otherwise be the case if it was considered for the right projects.


Clark, A. (2014, February).  Software Development Methodologies.  SAPM.  Lecture conducted from University of Edinburgh.

Sommerville, I.  (2007).  Software Engineering.  Harlow, England: Addison Wesley

Mikoluk, K. (2013).  Agile vs Waterfall: Evaluating The Pros And Cons.  Retrieved 9 Feb 2014, from

Haughey, D. (2009).  Waterfall v Agile: How Should I Approach My Software Development Project?  Retrieved 9 Feb 2014 from

‘Melonfire’ (2006).  Understanding the Pros and Cons of the Waterfall Model of Software Development.  Retrieved 9 Feb 2014 from