Among software engineers, the deletion of code is a celebrated act, as it typically represents the discovery of a more elegant expression of a solution. Famous anecdotes exist about the engineer who confounded his managers by reporting his productivity as “-2000 lines” (Bill Atkinson of Apple, Inc), as well quotes such as that attributed to Ken Thompson of Bell Labs, “One of my most productive days was throwing away 1000 lines of code”. Removing code typically represents refactoring an existing solution to reduce unnecessary complexity, duplication, or other manifestations of software-bloat. Deleting code removes an opportunity for confusion, and the fastest executing code is that which does not exist. Removing code is indeed a pleasure, earned as the reward for diligent refactoring, or intelligently removing complexity. I contend that deleting comments (or otherwise avoiding having to write them in the first place) can be similarly rewarding.

Drawing from a combination of the writings of various computer scientists and software engineers on this topic, as well as my own personal experience, I will explore what drives us to comment code and argue that in many cases comments may represent an opportunity for misleading the reader, or that writing a comment potentially represents a failure to refactor for clarity or to enforce invariants by design.

I will aim to convince that in many cases, comments can and should be omitted in favour of self-documenting code which enforces its invariants by design, and that comments represent an opportunity to introduce redundancy and repetition into the codebase. I will conclude that comments should be avoided wherever possible by refactoring code, introducing automated tests as executable documentation (or by providing some other form of executable API samples), while conceding that some comments may remain necessary (such as when a third party dependency is known to be defective resulting in strange usage) and considering how best to handle these cases.

# Why do we write comments?

The basic argument for writing comments is that source code serves the dual purpose of generating an executable program via a compiler or interpreter, and as a means of conveying the program to human readers (i.e., other software engineers). The source code represents the current state of the behaviour of program; it is the construction-site on which all software engineers will work. As on a larger software team, it is unlikely that all software engineers are likely to be familiar with all aspects of the source code, and will therefore need to be able to read, understand and modify source code that they have not written. Source code is likely to be read far more than it is written (as it will be read by potentially many engineers who did not write it); therefore any steps that can be taken to increase the understandability of source code for its human readers will likely pay off over the long term. The argument is that by writing high level natural language comments describing the intent behind a module, class or method, the source code is then more easily digestible for humans (and the compiler or interpreter is ambivalent).

The received wisdom is that there is a hierarchy of quality of comments, ranging from least useful to most useful. The least useful describe what the code does, essentially augmenting the source code with its natural language description, such as;

++ i; // increment i

This class of comments is considered poor form as it obviously adds little to the comprehensibility of the program; it literally describes what the source code statement does, adding no information.

The next category of comments, considered somewhat more useful are comments detailing how the code does what it does, which can add some value. Consider the following code listing for computing an approximation of a reciprocal of the square root of a number;

// inverse square root with 1st order approximation of Newton's method
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y;
i = 0x5f3759df - ( i >> 1 );
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) );

The implementation shown above is lifted directly from the Quake 3 source code [2] (with the more colourful comments elided); clearly the comment (which is not present in the original source) adds some contextual information that assists a reader, who may otherwise be confused about what the program is trying to accomplish.

The final category of comments, typically considered the most useful, are comments which describe the why, signalling the higher-level intent behind the augmented code. For example;

// The following code computes the reciprocal of a square root, to a // first order approximation using Newton's method
// This method is required for performance reasons for lighting 
// calculations, as 1.f/sqrt(num) is too slow on target 
// hardware on [target hardware, target compiler]

This high-level intent is not expressed by the source code implementation itself, so this class of comment adds information to the source code which is otherwise not possible to determine from reading it. Other examples of this category of comment are explanation of why a more complicated algorithm was favoured over a simpler one, or why a specific but non obvious order of operations is required, due to some subtlety.

Of these three categories, instances of the first two are almost always candidates for removal via refactoring, as will be discussed in the following section. This is sometimes the case for the final category also; note that the why categories of comments also carry the additional danger of becoming out of date, but this being impossible to determine from the source code (due to it conveying concepts not expressed in the source code), which can lead developers to introduce defects based on misunderstandings caused by misleading comments. This is because source code is rarely the authoritative statement for high level decisions unrelated to the code (such as business domain decisions), so including this information in the source code comments is a form of “don’t repeat yourself” ( DRY) failure (as described by  Hunt & Thomas in The Pragmatic Programmer [8]), and carries similar risks to software repetition. This phenomenon, that comments can actual serve to obscure the intent of the source code, is described by Yourdon in Techniques of Program Structure and Design [3]. Several of the lessons in The Elements of Programming Style [6] by Kernighan and Plauger relate to the dangers of comments, expressed by the maxims to “ensure that the code and comments agree”, “don’t comment bad code, rewrite it”, and “don’t echo the code with comments”. The next section of this article will explore the idea that “The proper use of comments is to compensate for our failure to express ourself in code” [1].

# Comments May Represent Failure To Refactor

Consider a system which conveys invariants to API consumers via comments, such as the following method signature;

* Method - UpdateThermostat
* Arguments - temperature. This value represents the temperature to 
* set the thermostat to. This value MUST be valid value in degrees 
* Kelvin, where 0.f is absolute zero.
void UpdateThermostat(float temperature);

This comment appears to be useful, as it conveys information which the method signature does not. However, the signature itself could be refactored to enforce its invariants. By refactoring such that a type is introduced to abstract the notion of a temperature, the invariants can be enforced by construction.

class Temperature {
    double valueKelvin;
    Temperature(double value):value(valueKelvin) { }

    static Temperature FromKelvin(double kelvin) { 
        /* validate value in range or throw exception */ 

    static Temperature FromCelcius(double celcius) {
        /* convert to kelvin and call FromKelvin() */ 

    double GetAsKelvin() { return valueKelvin; }
    double GetAsCelcius() { /* convert to celcius and return */ }

By using this data type as part of the API, the method signature becomes;

* Method - UpdateThermostat
* Arguments - temperature. This value represents the
* temperature to set the thermostat to.
void UpdateThermostat(Temperature temperature);

This method can then rely on the invariants being enforced in the Temperature class, reducing the need to validate the parameter (reducing DRY fail if temperatures are used in multiple places). This method also abstracts the UpdateThermostat method from the underlying data type used to represent the temperature. Crucially, this method no longer needs to state its invariants in a comment header as they are enforced by the type system. This demonstrates that many benefits can be derived by selection of a better design, and the presence of comments is an indicator that a better design choice is available. After the refactoring, the comment header adds no additional information beyond the method signature, and is a candidate for removal.

Another common example of an invariant which is stated via comments is the implicit sequence of valid operations for a class. Consider the following example;

* Class - Database
* This class abstracts a database to allow queries to be executed. 
* Users MUST call Connect() before executing any queries. It is an
* error to call ExecuteQuery() before connect has been called.
class Database {
    bool Connect(Credentials credentials);
    bool ExecuteQuery(string query);

Again, this comment appears to be useful as it adds semantic information which the code API itself does not present to the consumer. However, this comment also represents a failure to refactor the design. The Database class has two responsibilities; connecting to a database, and executing queries. These responsibilities could be separated into their own dedicated classes, which could allow the invariant described in the comment to be enforced by the system design. Consider the following refactoring;

class Database {
    DatabaseConnection Connect(Credentials credentials);

class DatabaseConnection {
    bool ExecuteQuery(string query);

By extracting the responsibility for performing queries from the type which is responsible for making connections, the system can enforce that it is only possible to perform a query from the result of a connection. By doing so, the system can enforce its invariant that the Connect() method is called prior to calling ExecuteQuery(), by providing access to ExecuteQuery() via the result of a connection.

Refactoring to eliminate comments can be applied at the statement level, as well as at the level of API design and interaction between components. Consider the following code, which exists in the context of some commerce application;

// calculate total cost by applying 20% sales tax rate
result = x + (x * 0.20);

Again, the comment does serve to clarify the intent of the code. However, the code also contains a magic number and non-descriptive variable names. By addressing these other deficiencies, the utility of the comment is reduced.

// calculate total cost by applying 20% sales tax rate
const TaxRate = 0.20;
totalCost = preTaxCost + (preTaxCost * TaxRate);

This can be refactored for further clarity by extracting a method;

// calculate total cost by applying 20% sales tax rate
totalCost = ApplyTaxRate(preTaxCost);

The initial comment now seems absurd in this new context; in addition to stating what is obvious from the code, it also conveys implementation details which may be misleading, should the tax rate change and the ApplyTaxRate method be updated. This illustrates how seemingly innocuous comments can contain DRY (Don’t Repeat Yourself) violations, as the information in the comment can become out of date and stale, such that it no longer conveys the intent of the source code it attempts to describe. As the pithy quote attributed to Ron Jeffries states, “Code never lies, comments sometimes do”. The earlier example from the Quake 3 source would be a good candidate for this simple refactoring, where an appropriate method name could remove the need for the comment to explain the obscure implementation. Writing “exceedingly clear”, verbose code is advocated for by David Heinemeier Hansson in [4]. In Refactoring [7], Fowler captures the essence of refactoring to eliminate comments; “When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous”.

# Avoiding Redundancy – Executable Documentation Via Automation

Given that source code comments may exhibit problems such as redundancy and repetition, it is worth considering what alternatives are available for filling the role that comments play in providing a high level description of program behaviour. A suite of automated unit tests can help convey the intended usage of the components in the program, and integration tests can illustrate the interactions between components. Well named tests which capture usage scenarios can serve the same purpose as comments in describing the invariants of the component under test. A significant benefit of automated tests is that the tests are more likely to be maintained, as the will (hopefully!) fail if aspects of the program change, such as invariants or expected behaviour. Additionally, documenting behaviour through tests requires that the software be designed in a testing-friendly (i.e., loosely coupled and highly cohesive) manner, further clarifying the API and reducing the need for comments as the responsibilities and capabilities of components should be clear. Automated testing therefore represents a good alternative to comments for program documentation to be consumed by software developers working on the project.

To accommodate external consumers of the program who are not primary developers (such as downstream users of a software library), it may be necessary to include comments. For example, a business client may insist on class or method level comment headers. If this is the case, there may be a “natural” canonical source of documentation or specification of the domain rules for the software. Ideally, comments should refer to other canonical documentation sources so as to not introduce repetition. For library consumers, another possible documentation method could be a set of (ideally automatically testable) API examples of the various use cases of the library, which can be used to demonstrate functionality without having to describe the current behaviour in natural language. If these API examples were automatically tested, regressions of API breakages could be detected, whereas a comment or document describing how to use the library to achieve the use case may break silently.

# Comments Are A Useful Crutch And May Sometimes Be Required

This article has presented arguments for the benefits which can be derived for refactoring to remove comments, in terms of software clarity and enforcement of invariants. Automated tests and API examples have been suggested as possible mechanisms to derive similar benefits to comments in terms of providing a higher level description of the software behaviour, with the added benefit that automated tests are inherently self-validating, so should be more resistant to becoming stale and outdated.

Other categories of comments can be potentially be replaced with more appropriate tools. For example, the classic TODO or FIXME comment could be replaced with a bug tracker describing the undesirable behaviour of the current implementation or design, and could be used for tracking possible remedies for the the problem. This has the benefit of integrating a more formal life-cycle for these types of annotations to the source code, such that these defects can be categorised and searched for, resolved or waived, etc. By adopting this approach, the tracking of technical debt can be made more transparent and available to non-technical team members, rather than informally captured as source comments. Similarly, NOTE and BUGFIX comments may represent a failure to use descriptive log messages when committing code to project’s version control software (VCS). Common VCS features such as blame can be used to investigate the history of the source code.

Despite the arguments presented here, it would be remiss to suggest that it is practically possible to remove all source code comments, or that this is even a reasonable or worthwhile goal. Sometimes comments are necessary to explain a strange or unexpected interaction with a third party dependency, such as a workaround for a known defect; sometimes they are required to explain why an obvious and well known algorithm for solving a problem hasn’t been implemented. Perhaps an iterative solution for a naturally recursive problem has been selected due to stack size limitations. These types of comments strive to explain the why, but critically it is a why which is answerable in the domain of the implementation, and expressible solely in the source code, such that there is no risky repetition of business rules.

Agile coach Tim Ottinger states in his short article on the subject [5] that comments are expressing a deficiency in the code, that the code has failed to meet the natural expectation of the reader, and should therefore be considered as “apology notes”. These apologies may be for a failure to refactor to remove problems, for not being able to use a well known algorithm (or for requiring a hand optimisation due to an earlier decision to favour a non-optimal design), or for simply having written hard to understand code. Ideally when reaching for a comment as the tool to solve a problem in your source code, ask if the comment is explaining away a deficiency in your design. Can the solution be implemented in such away that the comment becomes unnecessary? Would renaming variables or extracting methods help clarify intent? Would splitting up a module to better encapsulate its responsibilities help avoid a breakable invariant by design? Is your comment replicating information form a canonical source which may be subject to change? It may be that time pressures or other constraints require that the comment be written, or it may be that the comment really is required to convey information in the domain of the implementation that would otherwise be impossible to ascertain, and which could not be more appropriately conveyed in another medium. When adding these types of comments, consider what would be required to remove the comment, be it a bug-fix from a third party, or redesigning a poor interface and write this in the comment. Then, when the underlying issue is fixed, delete the comment.

# References

[1] Martin, Robert C. “Clean code: a handbook of agile software craftsmanship”. Pearson Education, 2008.

[2] Quake 3 Arena. Source Code Listing. URL: https://github.com/id-Software/Quake-III-Arena/blob/dbe4ddb10315479fc00086f08e25d968b4b43c49/code/game/q_math.c#L552 (last accessed: 21/02/14)

[3] Yourdon, Edward. “Techniques of program structure and design”. Prentice Hall PTR, 1986.

[4] Hansson, David H. “Clarity over brevity in variable and method names”. URL: http://signalvnoise.com/posts/3250-clarity-over-brevity-in-variable-and-method-names (last accessed: 21/02/14)

[5] Ottinger, Tim. “Apologies In Code”. URL: http://butunclebob.com/ArticleS.TimOttinger.ApologizeIncode (last accessed: 21/02/14)

[6] Kernighan, Brian W., and Phillip James Plauger. “The elements of programming style”. New York: McGraw-Hill, c1978. 1 (1978).

[7] Fowler, Martin. “Refactoring: improving the design of existing code”. Addison-Wesley Professional, 1999.

[8] Hunt, Andrew, and David Thomas. “The pragmatic programmer: from journeyman to master”. Addison-Wesley Professional, 2000.


Cloud computing


“What’s the cloud?” “Where is the cloud?” “Are we in the cloud now?!”

In the simplest terms, cloud computing means storing and accessing data and programs over the Internet instead of your computer’s hard drive. The cloud is just a metaphor for the Internet. It goes back to the days of flowcharts and presentations that would represent the gigantic server-farm infrastructure of the Internet as nothing but a puffy, white cumulonimbus cloud, accepting connections and doling out information as it floats.

In science, cloud computing is a synonym for distributed computing over a network, and means the ability to run a program or application on many connected computers at the same time.

Cloud computing is the next stage in the Internet’s evolution, providing the means through which everything — from computing power to computing infrastructure, applications, business processes to personal collaboration — can be delivered to you as a service wherever and whenever you need.

Cloud computing has four essential characteristics: elasticity and the ability to scale up and down, self –service provisioning and automatic deprovisioning , application programming interfaces (APIs), billing and metering of service usage in a pay-as-you-go model. This flexibility is what is attracting individuals and businesses to move to the cloud.
The world of the cloud has lots of participants:
• The end user who doesn’t have to know anything about the underlying technology.
• Business management who needs to take responsibility for the governance of data or services living in a cloud. Cloud service providers must provide a predictable and guaranteed service level and security to all their constituents.
• The cloud service provider who is responsible for IT assets and maintenance.

The benefits (pros) & advantages of cloud computing


Having your data and business computing programs running online, rather than exclusively on your office computers, means that you and your staff have access to them anytime, anywhere there’s an Internet connection. Small businesses like the idea of being able to access their data from home, at a client’s location, on the road, or even on a smartphone. And of course, if you know you will have to work disconnected, you can load the files you need onto a hard drive, a USB flash stick/drive or better yet use another offline/online cloud computing tool . Many of the more common cloud computing offers out there, such as Google Gears and Adobe AIR, make it possible for some Web-based programs to be used on a computer even when you’re not connected. That basically took one aspect that may have been viewed as a limitation and made it a huge plus.

Some of the more basic benefits/pros of cloud computing include:
• How it frees up physical space – Think of remote data storage, servers you’d otherwise have to to keep in house, etc.
• Cloud computing eliminates the needs for maintaining a cool enough environment for computer hardware that can easily overheat and crash.
• Saves electricity – in larger organizations this alone may be worth it.
• Eliminates the cost of maintaining one’s own IT staff to update and upgrade software or hardware because the data center handles that.
• Software & Hardware maintenance – Software provided online is upgraded and maintained by the provider, so the small business owner does not have to purchase the newest version of a software program or download fixes and patches for this or that server, router or hardware. Not having to buy a program outright but entering into a monthly or annual contract is very appealing, as is the fact that many applications are offered for free. The fixed cost allows business owners to plan rather than be caught off-guard when a costly software or hardware upgrade must be purchased.

For me personally, cloud computing has provided a sense of work-life balance. My personal budget, without any account numbers or anything except debits and credits, is in the cloud shared with my parents to simplify budgeting & updating. My to-do list is on the cloud. I email strictly now via the cloud. And best of all, my calendar is in the cloud. This affords me the flexibility to coordinate things between my personal life (more like several lives) and work. But enough about me.

The risks (cons) & disadvantages of cloud computing


The chief executive of leading security company Check Point, Gil Shwed, has warned enterprises from plunging too quickly into cloud computing, stating that the technology is inherently dangerous.

“The basic fact that you’re sharing data with others is a huge security risk. If I have my server with my data at least I know that I can protect my data, but if I mix hundreds of these [servers] there might be one bug, in one application, that will allow a virus to move to the others. A bug, a configuration error, anything.”

Shwed did not wish to discourage the move towards the cloud, however.

“I am definitely a supporter of cloud computing, but I don’t think it will take over from traditional computing – it will have some portion of the market. One of the things the enterprises want is control, and once you outsource … you lose a big portion of that control, so companies will only do this if there is a very, very, good reason,” he said.

“There is a clear and interesting challenge there, the move from controlling things to letting other people control it for you.”

While I don’t want to discount Mr. Shwed, you have to take his perspective into consideration. He’s in the security business. Naturally, it’s all about control; as evident by his quotes. As a small business or even a larger one (several larger ones actually), as I will mention in my conclusion below, some things are OK to relinquish control of provided the risks are understood and perhaps even mitigated. For example, I’m OK with relinquishing control of my email for my business or for most businesses I work with to cloud computing. The convenience and cost benefits out weight the control and risks (especially when they’re mitigated).

One of the biggest benefits of storing your data in the cloud is that you don’t have to worry about backing it up anymore. Big companies with hundreds of servers are more reliable than your little external hard drive, right? Yes. But servers do go down, and when you’re dependent on a web application to get your email or access that presentation for the big meeting, there’s always the risk that your internet connection will go down, or that the webapp’s servers will. Offline technologies like the previously mentioned Google Gears, decent export functionality, and a good backup system can alleviate this particular concern, but not all systems offer those things. Again, it’s about understanding the risks and mitigating them.

In conclusion …
It’s interesting that the government is behind cloud computing and has recently launchedapps.gov, a catalog of applications in the cloud. Despite the challenges of cloud computing, many large organizations are not only evaluating it, but are jumping to adopt it. Jaguar Land Rover moved to Google Apps. And the Los Angeles City Council today (if I wasn’t ill to write this on time – 2 days ago) voted unanimously to “Go Google,” (like Jaguar Land Rover) approving a $7.25 million contract to outsource the city’s e-mail system to Google’s cloud and transition some 30,000 city employees to the cloud over the coming year, according toa report in the Los Angeles Times.

In case you haven’t noticed, I personally am right on the cloud bandwagon with all of you. My web browser is the one app I run on my desktop at all times; I’ve entrusted the likes of Google, Facebook, Twitter, Dropbox, Amazon, and Yahoo with my data just like you have. The key is to know what you’re getting into when you make that choice, to crank up your personal security (like alternate email addresses and password choices) and to lobby for better user protection by hosting providers in the cloud.
It’s clear that cloud computing is a wave of the future. Ultimately, putting your data in the cloud involves choosing convenience and productivity at the cost of some security risk. In the real world, convenience almost always wins, and there’s nothing wrong with that. What’s important is that you understand the dangers. All you have to do is exercise some good judgment and practices and you ought to be able to alleviate many of the risks and challenges of cloud computing, leaving you to enjoy its many benefits.

Cloud Computing currently shapes the thinking of business modeling, business consulting, solution creation, service delivery, and software architecture design, development and deployment.

Response Article: Combining quantity and quality in large-scale projects

The specific post is a response to an article called “Combining quantity and quality in large-scale projects” by Ilias Galanopoulos.


The article is based on a chapter of a book called “The Mythical Man-Month”. As it is said in the introduction the post is working on finding an answer in the question: is it better to have a small group of really good programmers or a larger one with more that are mostly average programmers [1]? In other words, what is better, quality or quantity?

According to the book’s author in a large-scale project  it is needed to have groups with many programmers that work together as a team. However, it is really difficult for a  team to succeed harmony between the members. So, the solution is hierarchy. As in a surgery team, roles must be defined to the members. For example, the surgeon is the chief programmer and the copilot in the surgeon’s assistant etc.  The main advantages of this approach are that team members can work on a same task in order to save time and that discussions,which are time-consuming,  for a problem’s solution are avoided [2].

Finally, in the post’s last subsection the author comments about the writer’s approach of the subject and writes his opinion.


Firstly, I believe it is important to mention that I disagree with the opinion that the chief manager must make the decisions and the other member must do whatever he says. It is a matter of fact that if all the members of a group are equal then everyone would say and insist on the way that a problem should be solved and the result would be a contemporary “Babel”. However, it is significant for the chief manager to be open-minded and have the ability to listen to many opinions and discuss with all the group members and, as a result, decide which is the most appropriate  way to handle a situation.

Secondly, another point is the opinion that a solution is to use experienced programmers in important roles in the group  and bad programmers in tasks like testing. This solution could be efficient under specific circumstances. It is important for the leader to find the good programmers that will play the leading roles in the team and not to “sacrifice” good programmers in not so important tasks. Furthermore, it is also significant the not so good programmers not to feel like they belong to another team and be in an environment that do not underestimate them and pay attention to their opinions. This has as a result the team to communicate well and maintain in a good vibe. Under these circumstances I could say that I agree with the author in using this solution.

Finally,  in my opinion, the best way to manage a team in a large-scale project is mentioned at the end of the post. I agree totally that the best way is the divide the team members according to their speciality [2,3]. Like testers, engineers and administrators. However, I disagree with the fact that the post’s author does not analyse this solution as much as he could but insists in not so efficient ways to manage groups.


If I wanted to come to a conclusion, I could say that the post’s author has done a good job in the background analysis of the team management and some of the best ways to do it. Moreover, I think it would be better to write more about his opinion in the last suggestion.



[1] Frederick P. Brooks, Jr.. 1995. The Mythical Man-Month (Anniversary Ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

[2] Galanopoulos Ilias, 2014 , Combining quantity and quality in large-scale projects,  https://blog.inf.ed.ac.uk/sapm/2014/02/14/combining-quantity-and-quality-in-large-scale-projects/

[3]  Software Engineering: Principles and Practice – Third Edition – Hans Van Vliet – Chapter 3 – 2008


Formal verification in large-scaled software: Worth to ponder ?


Testing is an integral part of software life-cycle where most professional companies invest heavily on. There is an endless debate on which conventional test methodology is better because all share one common characteristic: they are good at discovering system misbehaviors but incapable of ensuring correctness. Formal verification offers the programmer the tools to ensure (in various rigor levels) that his program meets the imposed specifications. Of course, this ability comes with a cost: formal methods can be either very computationally expensive or highly non-automated and thus not an option for the majority of software companies which value productivity over (the highest) quality. In this article we argue that formal verification has still a place in the industrial development cycle of large-scaled software despite its computational bottlenecks. As we are going to show, formal verification is essential for some parts of the software where it is hard for the programmer to predict all possible cases and thus the danger of software unexpected failure is evident.

Formal verification and its limitations

Formal verification methods are a set of mathematically-based techniques which draw mainly from logic calculi along with automata theory and provide a framework where the (software or hardware) system’s specifications can be expressed in a notation with precisely defined semantics. Furthermore, the validity of these specifications in the system can be proved with the use of inference. Formal verification methods can be divided in two main approaches [1]:

Proof-based verification: In a proof-based approach, the system is represented as a set of logical formulas S and the specification as another formula φ (usually of the same logic as the system). The verification is the process of trying to construct a proof which shows that S ⊢ φ (i.e. that φ is proved by S). This approach can deal with infinite state spaces but, due to undecidability, requires human guidance for non-trivial proofs.

Model-based verification: Here, the system is represented by a model Μ (a transition system) and the specification is verified upon that model with the use of a temporal logic. Temporal logic is a special kind of logic where the truth value of a formula does not have a constant value but changes dynamically as the system moves from one state to another. For a given formula (specification) φ expressed in temporal logic the model is checked for semantic entailment of φ (M ⊨ φ). The process of verification is fully automated because we are dealing with finite-state models.

Although recent studies [2] confirm the usefulness of formal methods in industry, none of them is widely adopted because of their scalability problems. Even for small programs, proof-based methods require a big number of proof obligations to be discharged with many of them being too complicated for automated theorem provers to deal with. For these proofs, human guidance is essential (at least for “breaking” the proof into simpler sub-goals) which is costly for the company. Similarly, the size of the transition system (the model M) grows exponentially in respect to how many variables are present in the system so, for very big systems, the number of states to-be-checked becomes intractable. This is known also as the “state explosion problem” [3]. The above reasons make the full-scaled appliance of formal methods in industrial projects infeasible.

Apply it where it matters

Apart from critical systems (e.g. medical software/hardware, automated pilot software or nuclear reactor management software), where full-scaled formal verification is the only option, it is our opinion that formal verification can be beneficial when applied in non-critical systems despite the extra cost. The idea is simple: formal verification should be applied only to the most error prone parts of the software and leave the rest for conventional testing techniques to deal with. Of course, the key here is to correctly identify which parts of the project are the most error prone. To answer to that question we first have to think about the people who actually make the software. No matter how experienced a programmer is, his mind has an upper threshold of how much information is capable of processing simultaneously. If this threshold is exceeded then the probability that a bug is introduced increases. For example a programmer is unlikely to make an error when writing output commands but the opposite is true when synchronizing threads. Given all this, we think that software complexity metrics [4] (such as cyclomatic/Halstead complexity, coupling, cohesion etc… ) must be utilized in a attempt to identify which software segments require deeper analysis and use formal methods only on them. The use of formal methods in these parts can be invaluable because they are able to reveal system inconsistencies and ambiguities that otherwise would be very difficult (or even impossible) to be discovered (e.g. a counter-example that contradicts a programmer’s assumption about the system). Finally, the insight gained from the application of formal methods may lead to some sort of refactoring which, in turn, could increase the system’s efficiency or extensibility.


In this article we presented the two main approaches of formal verification, their scalability problems and the way that industry should include them in software life-cycle. Complexity in code is the major factor that introduces difficult to detect bugs so the most powerful yet expensive verification techniques should be applied only on code segments where complexity metrics indicate potential danger.


[1]: M. Huth and M. Ryan, Logic in Computer Science: Modelling and
reasoning about systems. Cambridge University Press, 2004.
[2] J. Woodcock, P. G. Larsen, J. Bicarregui, and J. Fitzgerald, “Formal
methods: Practice and experience,” ACM Computing Surveys (CSUR),
vol. 41, no. 4, p. 19, 2009.
[3] A. Valmari, “The state explosion problem,” in Lectures on Petri nets I:
Basic models. Springer, 1998, pp. 429–528.
[4] Measuring software. A. Clark. University of Edinburgh, 2014

Response article: Behavior Driven Development by s0937917

In response to ”Behaviour Driven Development: Bridging the gap between stakeholders and designers” by s0937917 [1]

1. Introduction

The author writes about the ideas of Behavior-Driven Development (BDD) in relation to the communication divide that is often perceived between developers and other stakeholders of a project, with the other stakeholders mainly referring to the clients. This communication divide can lead to internal problems in translating a customer description into something more akin to a technical specification. A somewhat hyperbolic, albeit clear analogy, is that of the tree swing, used by the author as an example of what he or she means. These specification problems can then supposedly be mitigated by the use of BDD in any given project.

2. Points of disagreement 

As much as I agree with this premise, there are certain points made in the article that I do not necessarily agree with. There are definitely upsides of BDD, a methodology with promising characteristics, such as the similarities between the user stories and the resulting implementation. It tries to mimic the business language used to describe the characteristics of the product in question. Considering that the tests serve as the basis for the implementation, the need for modeling languages such as UML, or other forms of explicit modeling and documentation, is diminished.

However, my disagreement is with the assertion that it solves the communication problems between the client and the engineers. An example used in the article was: ”as a service subscriber I want to click on the poster for movie X and is launched in the same window”, out of which several questions arose. Now, using a BDD framework might help make the translation of the user story into its subsequent test much clearer than, say, using plain JUnit. I fail, however, to understand how the use of BDD solves the problems arising from the initial user story.

These problems, or questions, were of the following nature:

  • ”If the user clicks “open in new tab” should the browser just launch the video player or the same page with the player embedded to allow deep linking?”
  • ”If the user had started watching the movie earlier closed the browser in the middle, should the movie start over or continue from where it was left off?”

These are aspects directly related to the functionality of the application. The author goes on to say that they can block development and lead to developers or program managers having to contact the clients and wait for an answer. The main problems lies with the assertion that this is somehow not desirable. I will argue that it is, and furthermore, that it is one of the cornerstones of agile development [2]. The clients need to be regularly involved in the development process, and it is imperative that both the engineers and the clients understand this from day one. BDD is not a replacement for iterative development and continuous communication. The necessity is made even clearer considering the fact that we know the least about the requirements in the beginning stages of a project [3].

Another consideration is of course the technical expertise of the client. I would argue that the communication is even more important in projects with non-technical clients, who will not necessarily review the code base. In such circumstance, BDD seems promising in its ability to effectively translate business requirements into test cases, but again, this differs from getting those business requirements right in the first place. The business requirements are always courtesy of the client and therefore it would be dangerous to make any assumptions with regards to the questions that arose following the initial user story given as an example above. BDD cannot answer the question if the application should allow streaming of multiple movies at once, only the client can.

Client or customer feedback is a fundamental part of getting things right in an agile project. An interesting approach is that of Complaint-Driven Development [4], somewhat humorously outlined in a Coding Horror blog post. Such an approach explicitly emphasizes the developer-client relationship and the never-ending feedback cycle between the stakeholders.

Lastly, the author highlights another interesting issue in the ways that developers think. Engineers and testers think in code. Most often, clients do not. Dealing with this problems is arguably the single most important characteristic of BDD. It helps developers understand requirements in a different manner, a manner that is tighter coupled with the user story. With that in mind, I agree with some of the conclusions made about BDD in the original article, regardless of my critique of its capabilities in this brief response.

3. Conclusion

It certainly does seem to push for better code standards, meaning that the relation between the business description and the code is not arbitrary. They both follow the pattern of: Given some condition X—> When I do Y —> Z happens. If this is inherently better than any other method is difficult to say, but it certainly makes the code clear, concise and thus, arguably, easier to maintain. It does not, however, solve the communication problem, nor is it even intended to in my mind. It does overcome the translation problem, but the requirements must still be defined, and as clients, we do not always know what we want right from the start.


[1] https://blog.inf.ed.ac.uk/sapm/2014/02/14/behaviour-driven-development-bridging-the-gap-between-stakeholders-and-designers/

[2] http://www.allaboutagile.com/agile-principle-1-active-user-involvement-is-imperative/

[3] A. Clarke, ”Software Engineering Process and Management”, University of Edinburgh, 2013/2014

[4] http://www.codinghorror.com/blog/2014/02/complaint-driven-development.html

Response article: Being large and agile


This post constitutes a response to the article entitled “Agile Methodologies in Large-Scale Projects: A Recipe for Disaster” posted by the user s1044415 on 14/02/2014 [1]. Starting from the agile manifesto [2], the author questions the feasibility of agile methods in large-scaled software. More specifically, for every of the so-called “agile values” presented in the manifesto, the author provides arguments which make the agile methodologies look problematic when implemented on real industry scenarios and support traditional heavy-weight development practices. Here, we argue that agile software development is something more than a bunch of guidelines and that it has its place (to a different extend) in every large-scaled project.

Client wants software not documents

The first step to become agile is to realize that, in the end, the customer wants an efficient piece of software which does what it is supposed to do. No one (maybe except from archivists) find diagrams and extensive documentation any useful given that the software works correctly and efficiently. There is nothing unprofessional in not providing extensive documentation. On the contrary, it is the definition of professionalism to provide the client a prototype as soon as possible and receive early feedback which could have a strong impact on the future development decisions (this is one of the core agile recommendations). The fact that many old-school businessmen feel secure when surrounded by diagrams is a result of habit and does not consist by itself an argument for not being agile.

At this point, it is important to emphasize that the power of agile practices derives from the fact that there are not strict rules to be followed as opposed to heavyweight processes. A direct consequence of this is that maintenance documentation is not prohibited but encouraged. Maintenance documentation records the architectural patterns after the completion of a module and provides information for further expansion capabilities but does not function as a guide during the construction. It is also much smaller in size (less effort for the developers) because it contains one (final) version and not multiple. Finally, the author provides an example in which extensive documentation is exploited as a proof in the hands of a government in the case of a project failure. Again, revised UML diagrams are unlikely to persuade other parties or individuals that their money were not wasted. On the other hand, clearly defined aims of the project combined with honest reasons of failure may have better luck. None of the above is discouraged by the agile standard.

Do processes and tools really work ?

It is claimed by the author that the reason processes and tools are used in large-scaled software is because they work. Let’s stand a minute and think of what we mean when we say that something “works”. If “works” means that, in the end, the client paid for a piece of software that was useless after a short period then yes, these processes and tools actually work. But if the objective is to provide the client with a piece of software that he can actually depend on long-term, processes and tools are not capable at all. The reason is rather simple: every project is unique in terms of aims and (possibly) of technological combination. These peculiarities demand innovative approaches and cannot be expressed in recipes. Software engineering is not cooking. At the same time, the re-use of an existing block of code is not something that is necessarily non-innovative. For various reasons the development team may decide that some repository code can be utilized in order to accelerate development without sacrificing code quality. The elegant combination of existing code still requires innovative minds since it is not by any means a trivial task. Moreover, the author claims that innovation and originality brings chaos. It is our opinion that chaos is brought by practices which promote isolation and competition among the team members (a common characteristic of the traditional methodologies). Agile recommendations considers communication as a crucial factor for success. Innovation comes through continuous collaboration among all the team members thus eliminating any danger of chaos.

Client as a co-developer

In his article, the author makes the assumption that the client knows what exactly he wants from the very beginning. This could be the case if the client is himself a software engineer but unfortunately this is not the case in most situations. Changing requirements is the most common cause of project failure. By agreeing on a contract from the very beginning the developers commit themselves in a target that in many cases may be infeasible or not what the client has in his mind. Human mind is able to acquire a much larger amount of information from something that it observes compared to a description. Agile standard exploits that property by recommending the construction of a prototype as soon as possible in order to receive an initial feedback from the client and then a continuous flow of releases where more feedback can be acquired. By this way the developers are in a position to identify possible misconceptions on time and change their plans accordingly. Continuous integration with the client do not expose the developers in any danger of exploitation. This is because there is a distinct line between the core functionality of a project and additional features which an experienced programmer is in position to identify. After all, if the client is willing to wait and pay more for some added functionality then so be it! Finally the author argues that a clearly defined plan increases the chances of a good estimation on time and budget. We strongly disagree with this notion because we believe that an early prototype offers an invaluable insight to developers regarding the projects peculiarities (because it exposes them directly to implementation rather than chatting while looking diagrams) and thus a much more accurate estimation would be possible.

The one who adapts survives

Given the current fast-changing business environment it is our opinion that following a strict plan from the very beginning is simply not an option anymore in software industry. Things change rapidly and along with them the clients requirements. If a software company wants to be successful (by providing their clients competitive software) it should welcome late changes in requirements. This is the main reason that agile methods are becoming more and more popular. We agree with the author in that the information flow in large-scaled project is a very important factor for success and requires rigorous procedures if confusion is to be avoided. But in this moment is where the “loose” nature of agile recommendations shines. No-one says that in order someone to be agile must follow by-the-book all the principles. Intentionally these principles are vague because their goal is to provide a high level way of thinking, not a look-up table for developers to use. Project managers (yes, there is not a rule which forbids managers!) can use hybrid approaches which on the one hand are conventional in terms of communication among separate teams but on the other hand utilize all the benefits agile standard has to offer in all other aspects of the development software process. Manager is tasked the weight of defining the threshold of where agile stops and typical procedures start.


In this article we tried to give justified counter-arguments in response to [1] regarding the application of agile methods in industry. Agile recommendation have much to offer to large-scaled project development and any limitations can be overcome by utilizing hybrid approaches. The intentional vagueness in the agile principles as presented in [2] is the key which makes them applicable to all software projects.


[1] https://blog.inf.ed.ac.uk/sapm/2014/02/14/agile-methodologies-in-large-scale-projects-a-recipe-for-disaster/
[2] http://agilemanifesto.org/
[3] Get ready for agile methods, with care. B. Boehm. IEEE Computer 35(1):64-69, 2002.
[4] Software development methodologies. A. Clark. University of Edinburgh, 2014

Why Pair Programming Is The Best Development Practice?

 Let’s do some pair programming!” – this phrase may one day discourage you from working in your dream software company.

There are many claims supporting extreme programming and pairing in general, but you think that this is not for you.

If you believe that working solo is the best way for achieve great focus in a creative process known as software development…


Cowboys ain’t fun anymore

Recall your best programming experience. Do you remember when ideas were flowing through your head, hours were passing as seconds and you were experiencing constant feeling of a muse sitting next to you?

You might have experienced this several times, but unfortunately not very often. You probably think about programming as a creative process – sadly this is not relevant for every task. What about when you were working on bigger project? Interesting and creative core part was finished very quickly, but what was left as boring and extremely repeatable.

Guess what – your most programming tasks in a software company will focus on boring and repeatable tasks with very few of them being creative and challenging. Your performance will be measured by number of implemented features, lines of code and bugs fixed. In addition hard work will be valued much more than talent on its own. You will not feel productive and creative every day, but you will have to submit your results anyway.

Cowboys are of no value anymore. Heavily trained spec-ops of extreme programmers are.

Not even once!

Now we should hear some arguments against pair programming. Let’s start big [1]:

One of the most influential programmers (if not people) in the world, Steve Wozniak, famously advocates”:

“Work alone… Not on a committee. Not on a team.”

You might also add that some of the greatest minds in our history were introverts and they achieved great success by working solo (Darwin, Einstein, Newton). Of course you won’t mention the fact that those world-changing inventions were then developed, tested and introduced by dozens of scientists, engineers and businessmen, but it sounds like a good point against pairing in general. Lastly you may mention that about 30% people in the world are believed to be introverts [2] (and probably even more when we think about programmers), so pair programming must be a practice introduced by extroverts to control a process of software development.

Every claim mentioned above is probably true. We can all agree with them, but it doesn’t change values which may be gained from working together.

Let’s change our direction a little bit. Ask yourself extremely important question:

Have I ever tried pair programming?

If the answer is no – you should stop reading and try it. If yes and you are still not convinced – go to the next section. Maybe this is a case that you are doing it wrong.

Pair Programming 101

There are tons of examples and blog posts on the web of people sharing their bad experience when practising pair programming. There are thousands of stories of how evil pairing is and how wrong it is for creativity[1,3].

Let’s stop this. I believe that those stories exist, because people have no idea how to practice pair programming.

No one was born the best programmer in the world. People who are believed to be ones, gained their knowledge through hard-work, experience and hours spent on coding. The same goes with Pair Programming and social skills in general. Everyone needs some training.

Let’s consider some of the most important rules [5]:

  1. Pairs should be formed flexibly and naturally, rather than by fixed assignment.
  2. Keep fresh perspective by switching your partner frequently.
  3. Sit comfortably (with plenty of space for your feet and arms) side by side.
  4. Always use a big monitor (or more) and two keyboards.
  5. Collaborate with your partner, do not critique his work

Following those four important points should help you achieve success when working in pairs. In addition, we should consider a little bit more.

Pair programming is an important and crucial part of Extreme Programming (XP) methodology. This being said, we cannot use pairing without following rules from XP.

What XP tries to do, is to enhance team software development process, rather than single programmer process. XP shines in every piece of software that must be maintained (eg. development code). It means that spiked, innovative solutions  may benefit much more from different approach (eg. happy hacking).

Let’s think about Test Driven Development – it was invented to simplify and control development code with hundred (thousands) line of code. TDD works as milestones – one test resolves one problem. This means, that it give structure to your (unstructured) flow of thoughts.

As mentioned before, XP is team software development methodology. In a team everyone is average (or as good as weakest member). In order to make people better, we must follow a strategy when matching people into pairs. Let’s try to match people with the same skills in the beginning. Later on we can try junior plus senior programmer. This however must be realised with cautious – let’s give junior time to research important part of the project, which no one is expert in (eg. library). We should make everyone feel like an expert!

Last, but not least is to practice proper ways of communication. You may say that during pair programming people may start arguing or feeling bad. I will tell you – this is a problem with your team. Teambuilding is important, the same as practicing good manners. If we resolve this – we will resolve every problem.

We need a proof my dear Watson

There are plenty of articles, research and blog posts supporting pair programming. Pairing is all about collaboration and teamwork, thus it will shine when following aspects are considered [5,6,7]:

  1. A huge percentage of bugs and defects can be caught before release.
  2. There is a lot of knowledge sharing and project ownership involved in the process.
  3. Code design improves with significant reduction of number of code lines.

Those points will serve as a something well defined and thoroughly researched. In addition several well-known and respected programmers prefer pairing [5,6] and even more experienced developers may benefit from learning a new ideas.

The biggest objection against pairing is that it doesn’t leave you time for though. Demarco and Lister, in their experiment [8] found that the best factor for quality is not money nor experience, but how quiet the workplace is.

On the other hand, according to [5] people who are practising pair programming are experiencing flow (productive state of mind) more often and are experiencing less interruptions than solo programmers.

As the last proof, let’s hear some comments from people who used pair programming [6]:

The adjustment period from solo programming to collaborative programming was like eating a hot pepper. The first time you try it, you might not like it because you are not used to it. However, the more you eat it, the more you like it.

“It is psychologically soothing to be sure that that no major mistakes had been made . . . I find it reassuring to know that [partner] is constantly reviewing my code while I drive. I can be sure I had done a good job if someone else I trust had been watching and approved.

Is there an ultimate answer?

Yes! There is an ultimate answer to the question “Why Pair Programming Is The Best Development Practice?”. However the answer is a tricky one:

Pair Programming is the best development practice, because it is fun!

Pairing is not most suitable in every situation nor easiest one and probably not even the most effective one. It works well, shines in standard team software development, produce good results and strengthen team spirit. However the most important argument is that pair programming gives us a lot of fun, knowledge sharing and motivation in imagined-as-single-person task such as programming.


  1. http://www.bennorthrop.com/Essays/2013/pair-programming-my-personal-nightmare.php
  2. Schat, Sean. “Quiet: The Power of Introvert in a World That Can’t Stop Talking.”Brock Education Journal 22.1 (2012).
  3. http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming-and.html
  4. Shore, James. The art of agile development. ” O’Reilly Media, Inc.”, 2007.
  5. Cockburn, Alistair. Agile software development. Vol. 2006. Boston: Addison-Wesley, 2002.
  6. Cockburn, Alistair, and Laurie Williams. “The costs and benefits of pair programming.” Extreme programming examined (2000): 223-247.
  7. http://www.codinghorror.com/blog/2008/04/core-war-two-programs-enter-one-program-leaves.html

Response Article: Software Measurements in the eye of clients

This is a response article for the blog post “SOFTWARE METRICS, ADVANTAGE OR DISADVANTAGE”. It could be found here:


1. Introduction
In this blog post i am responding to an article about Software Metrics. My main point is: the author of the post said in the introduction that he will talk about measures from the client’s overview and then spoke about some traditional measures that are not even useful for people in the development team.

2. In response to the blog post
Software Metrics are important measures and they should be studied from two perspectives: people-inside the company viewpoint and clients viewpoint. We have seen in SAPM lectures that it is hard to estimate and measure software but we have to do something![5]

2.1. I got excited about this topic…BUT!
The blog post is started with a very interesting and thrilling point and I will put the exact sentence that took my eye: “Nowadays, customers need to know that what they are buying has the quality they need, otherwise they cannot use it and they will not buy it”. The author also stated a very nice example about buying a car. I was totally excited assuming that he will talk about software measures in the eye of customers. However, he continued his blog post stating the measures that MIGHT mean something for the software development team or manager BUT ,surely, not for the customer. The author mentioned a list of measures such as Lines of code, Number of classes & interfaces, Code to comment ratio, Code coverage…etc.

2.2. so what’s my problem with this blog post?!
The problem is that, all of these measures mean NOTHING to the customer. How in the world will a client decide whether a 4500-line-of-code is good or bad software?! Just imagine some client asking about your program and its quality and you tell him “Well, I have a 3500 lines-of-code in my program so it is amazing!”. It is not even useful for comparing! Who said that a 4000 line-of-code program is better than a 3000 line-of-code one?

2.3. COBRA Effect!
Further to that, these measures are really not useful neither for the manager of the team nor for the programmers themselves (recall. Lectures of Allan and Cobra effect…etc)[1]. If these measures are of NO USE neither for the manager nor for the programmers, how come will they be useful for the client? The same thing holds true for other measures you stated.

2.4. Successful Software Projects
Let me go to one of another colleague’s post “Easy facts about LOC used in software measurement” (https://blog.inf.ed.ac.uk/sapm/2014/02/11/easy-facts-about-loc-used-in-software-measurement) and take the following: “Clients care about the function. Only the business value brought by these function is meaningful. LOC is not a metric that could be used to evaluate how meaningful the function is. More code does not necessarily suggest that the function is robust or the business value is large”[2]. This is exactly the case. Clients care about what your software will give them whether it has 100 classes or 1000 classes or even 1 class!
Clients might be more interested in the main criteria for successful projects. They want the software to be done on time, within budget and meet their needs in scope and quality[3]. In case you want to tell your customers how good/bad you are doing in the project up to now, you should look for an easy-to-interpret and meaningful functional measures for clients. The client is interested in knowing how reliable my software is, how secure, and how efficient it is.

3. Conclusion
My point towards this blog post is that, in the introduction it gives me a feeling that it will provide us with measures from the viewpoint of clients, but then it goes into the traditional measures.
Taking into account all what I have just said, I am a 100% agreeing with the author that telling the client about our software is a real need whether as estimates, measurements when we are coding, or as an evaluation after finishing the Software. Speaking in terms of Reliability, Security, Efficiency, Maintainability[4] might be more useful and easier to understand for the client.

[1] http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/276
[2] https://blog.inf.ed.ac.uk/sapm/2014/02/11/easy-facts-about-loc-used-in-software-measurement/
[3] http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/6
[4] http://en.wikipedia.org/wiki/Software_quality#Measurement
[5] http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/235

Estimating Effort: Maybe we shouldn’t cling to it


Early in the SAPM course [1] we discussed estimating size and effort for software projects. We know this a nearly impossible task but a necessary one. Despite all the effort put into techniques and formulas that are supposed to help with this problem software keep being delivered late, incredibly late or never. Maybe what needs to be adjusted is not the process of estimating time and costs but the process of planning a project. We should instead expect to deliver a project with a few missing components that we can add later on. (This could explain the success of agile development: if a nonessential component is not ready, the project can still go on and be delivered)


Why is estimating project cost and size important? Because companies need these estimates to plan cost and human resources to allocate to the given project. Good estimates allow companies to commit to delivery dates for its product and not have to deal with unhappy customers, while bad ones  lead to projects going over budget, over schedule or even end up as runaway projects.


How is the world coping?

In an endeavour to handle this problem various techniques and formulas have been developed to help with time – effort estimation. As previously mentioned none are a perfect solution and it seems that the industry has come to accept that estimates are likely to be wrong, but they need a starting point so the described techniques will continue to be used.

There are three major techniques used for effort estimation: three point estimates, Wideband-Delphi estimates and COCOMO.

Three point estimates

The three point estimate is a formula for computing an effort estimate as a weighted average of an optimistic, a most likely and a pessimistic estimate.

In my opinion this is a simple and fast technique to get a rough effort estimate. Since we already know that estimates given at the beginning of a project are likely to be wrong and therefore a waste of time, it is preferable to move on as soon as possible.

Wideband-Delphi estimates

Wideband-Delphi estimating is a techniques for computing time estimates that requests the presence of a group of experts. They repeatedly discuss the implications of the project and give they own blind and anonymous estimation of project duration until all estimates are roughly similar. Giving a blind, anonymous estimate ensures the result is not influenced by external factors such as peer pressure.


COCOMO  is a formula for establishing effort estimates based on previous experience. This requires that all previous projects are well documented. In my opinion, relying  on previous experience is the best approach; however, it is likely to fail if the team changes as it is quite often the case in software development teams. COCOMO will be delivering optimistic estimates if suddenly several team members are replaced by other less experienced members; moreover the a team’s dynamics generally impacts the teams performance.

A technique that would help with damage control early on in the development process would be periodic reviews of the effort estimates they have committed to. This especially important as there are several factors that unknown at the beginning of a project and helps adjusting the resources to help with delivering the product.


Maybe there is light at the end of the tunnel

During an internship, I got to participate in my team establishing new projects to work on, and the process worked along the lines of “What can we do in the next year?” and “What can we build the the next three months” rather than “How long will it take us to build this project?”. The  yearly plan was vague and most likely to change but the quarterly one what we were really trying to achieve. In addition, the company’s policy was: “if you finish everything on time, then you haven’t challenged yourself”, so teams were encouraged to plan for more than they could realistically achieve in the given time. This also means that it was expected that teams would not attain all their goals for that period. Moreover, we were working on a project with frequent releases, so this made the concept of deadline rather non-existent, as anything that was not ready for release could wait for the next release.

I am sure many of you are wondering what keeps people from slacking off? The answer is: company culture. But this is another story. The frequent review of goals as well as the lack pressure from the company were very helped the team stay on track while trying to quickly move forward with the development process. 

In my opinion, this model can work even for companies with less frequent releases. As long as they prioritize the features they are trying to build. They can start by building the most important features or components first, and put everything else in an “if we have time” category.


As we appreciate the importance of structuring a large project: planning and allocating resources to avoid waste, experience has shown it it almost impossible to control all the elements that influence the successful completion of a software project. Experience has shown that adding structure to the process of building software is impossible and we should learn to live with the unforeseeable.


Repercussions of the Cloud

Recent years have seen a large rise in the use of cloud based systems, with the vast majority of companies claiming some form of cloud usage. Cloud Computing has many advantages to offer businesses; from cost savings through to the ability to have truly elastic resources manage demand volatility.

This blog will explore some of the repercussions of Cloud Computing, and the impact they have had/may have on software architecture, process and management.

What is the Cloud

Cloud computing refers to both applications delivered as services over the Internet, and the hardware and systems software in the data centres that provide those services [1].  There are several cloud computing service models, including SaaS, PaaS and IaaS.

SaaS, Software as a Service, provides access to application software. Examples of this include Google Apps and Microsoft Office 365.

PaaS, Platform as a Service, provides a complete computing platform upon which you can run your own software. A typical platform may include things such as an operating system, programming language execution environment, database, web server etc. Examples of this include the Amazon Web Services Elastic Beanstalk, and the Google App Engine.

Finally IaaS, Infrastructure as a Service, provides physical resources, such as machines (physical but most often virtual), storage, servers etc for use by the user. Examples include Windows Azure and Rackspace.

Why use it?

Cloud computing can offer several key advantages over more traditional approaches to computing, some of which include:

-Scalability: Cloud infrastructures can give the illusion of having infinite resources, which means you can make REALLY big stuff. [1] gives a good example of this: organizations that perform batch analytics can use the “cost associativity” of cloud computing to finish computations faster: using 1,000 EC2 machines for one hour costs the same as using one machine for 1,000 hours.

-Elasticity: This means that available resources can be increased or decreased elastically to respond to demand. This can be a HUGE advantage, because it means you don’t need to know how big your stuff is going to be beforehand!

Another example from [1] to illustrate this: when Animoto made its service available via Facebook, it experienced a demand surge that resulted in growing from 50 servers to 3,500 servers in three days. The elasticity provided by using a cloud based infrastructure was key to the service being able to function, as without the allocation of extra resources the service would have been unavailable. Additionally, when demand began to drop again after the initial surge, resources could be dropped such that the expenditure on the system more closely matched the workload.

-Accessibility: You can access your stuff anywhere you have an internet connection, which is most places, nowadays.

-Cost: Cloud computing can be a lot cheaper than whatever you were doing before. This is in part due to elasticity and being able to allocate/de-allocate resources, and in part due to the fact it costs big vendors, such as Amazon or Google, less money per resource than it would cost you.

How does this impact SAPM?

With Cloud computing being used so prolifically, it has affected software architecture, processes and management significantly, and will continue to affect in into the future.

Project Management

Project management is something that has been affected by the rise of cloud computing. A lot of applications are increasingly calling for forms of Agile Development, and cloud based software can benefit from this to an even greater degree than normal. Software requires continuous updating; bugs need to be fixed, security holes need to be patched, and new features need to be added. In a cloud setting, this can be done much more easily, as rather than have each user download an update or patch, the developer simply updates the software hosted on the cloud and when a user uses it the software has been updated

Let’s use Facebook as an example. Whenever you load Facebook, you are likely to load a different version of Facebook from the last time you used it as it is constantly under development. New features are very frequently (sometimes to the extreme annoyance of users). Interestingly, the version of Facebook your browser loads is not guaranteed to be the very most up to date version of Facebook.

Flipped around, you could say that agile development is essential to cloud based systems, as if you have the ability to respond to user demands this quickly, and don’t do it when a competitor does, you will instantly be at a competitive disadvantage. This was less the case when software came packaged, as the user had already bought the software, however under a pay per use model a developer must keep their product competitive at all times.

Capital Investment

One limiting factor in the past for many projects was that they needed a large up-front investment to get them off the ground, whether this be due to having to physically package and ship their product, or having to plan for worst case loads on a web based system.

With the ability to provide software as a service, the up-front investment on shipping and packaging products has vastly diminished, enabling to such projects to go ahead. Projects which previously had to plan for worst case load scenarios can now take advantage of the elasticity offered by cloud vendors to offer their services without having to expend money for resources which will be under-utilised.

Challenges to the Software Engineer

Software engineers now face many new challenges when working on cloud based projects. Firstly, it is typical for cloud based software to be accessed through a web browser. This in itself poses a challenge to developers, as it reduces the number of tools at their disposal. [2] explains this well: ‘The traditional window and menu layer of modern operating systems has been fine-tuned over decades to meet user needs and expectation. Duplicating this functionality inside a Web browser is a considerable feat. Moreover it has to be done in a comparatively impoverished development environment. A programmer creating a desktop application for Windows or one of the Unix variants can choose from a broad array of programming languages, code libraries, and application frameworks; major parts of the user interface can be assembled from pre-built components. The equivalent scaffolding for the Web computing platform is much more primitive.’. This is an ongoing challenge for developers.

Additionally, developers now need to build their software to deal with the infrastructures used by cloud vendors. This involves handling failures in hardware, and building software that works well in a distributed environment. This had led to the rise of new architectural  patterns, such as Google’s Map-Reduce architecture.


In conclusion, cloud computing has had, and will continue to have, a big influence on the area of software architecture, processes and management.





[1] A View Of Cloud Computing. Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia. 2010. Communications of the ACM 53, 4 (April 2010), 50-58.

[2] Cloud computing. Brian Hayes. 2008. Communications of the ACM 51, 7 (July 2008), 9-11.