Author: s0930891

Description of the Problem

This post will analyze and describe the most prominent issues and problems that result in the failure of software engineering projects. In 2004, only 29%[1] of projects were completed successfully, motivating the study to figure out where the problem lies and what can be done about it.

Success in a project primarily revolves around the satisfaction of the client. However, if it not up to their judgment, when broken down, a successful project is one that is completed on time, within budget and meets all the requirements as specified in the design. Even small botches in any of these aspects could constitute a failed project.

A project can be classified in one of two ways; challenged and failed. A failed project is one that does not work, or has been cancelled. A challenged project has less brutal pitfalls, i.e. it was over budget, over schedule or has not implemented all of the necessary functionality.

The question then remains, what are the biggest troublemakers in software engineering projects that make their success rate so low and is there a foolproof way to ensure that a project will be a success?

 

Cause and Effect

The first thing I would like to discuss is what happens when there is an absence of leadership within the team, creating many problems in numerous aspects of the project. This would include a lack of direction with regards to design and planning for the project, potentially resulting in time wasting or the project going over budget. You need someone to make decisions should the team get stuck as well as someone to be able to manage the team and make sure all the members are doing their job and doing it right. It is also important that the leaders ensure that each and every worker understands exactly what it is that they are doing which is just as important and the leaders understanding exactly what it is the client wants.

Secondly, it is vital that a business case for the project has been made before the project has begun. This aims to measure the likelihood for success financially. If the return on investment is less than the cost to create and maintain the software, it is not worth doing. There is also a delicate balance that should be made between quality and budget. This means that an estimate building cost must be calculated at the start, and bad estimating techniques can also be a hazard for any project.

However, accountability is not solely on the leaders and managers should the project not be a success. Having personnel that are talented, get along well and work hard will significantly increase the chances of the project being a success. Therefore, hiring a team of well-trained and enthusiastic individuals will certainly increase the chances of the project being a success.

The next potential hazard is poor or non detailed design. Not having a clear, outlined plan from the beginning is setting the project up for disaster. This could result in certain requirements being forgotten. It could even be that the project moves completely out of focus and time is spent working on functionality that is completely irrelevant to the problem at hand. The functional and non-functional requirements need to be gathered and understood as well as any other constraints. Constraints could include aspects such as what technologies are available or what integrations are necessary.

Another potential concern for failure could occur when using external software not produced within the project. This could result from members wanting to use the newest technology on the market that has perhaps not yet been tested thoroughly enough. In reverse, perhaps by not having enough money in the budget to purchase what you need, therefore having to rely on mediocre alternatives. Any time that third-party software is used; the project runs the risk of running into some problems.

Unexpected problems, whatever they may be, may arise that could cause some failures. You cannot predict or plan for every scenario and sometimes a disaster may not be in anyone’s control or of anyone’s doing. This could include things such as the client changing their mind on requirements, benefactors pulling out their funding, or even natural catastrophes that physically damaged all at the work that had been done until then.

 

Personal Experience 

            When I have worked on a software engineering project, the success or failure of it usually relies on how hard the team or I have worked on all the aspects mentioned above. Making decisions about the design at the start was always extremely important and useful, as was having a leader to take responsibility should there be a conflict to make the decision themselves. Therefore, from my individual experience, I believe that design and leadership are the two most essential factors to aid the success of a project.

 

Conclusion

            From the points and descriptions as stated above we can now try and summarize the closest to foolproof formula for success that exists in a software engineering project.  Each aspect is an important piece in the project puzzle as can be seen in the graphic below.

Unfortunately, even though the project management style might adhere to all of these factors as best as they can, issues out of their control may still arise and lead to problems.

There are many reasons why a project can fail, some are unavoidable and some can have their likelihood of occurring reduced with proper planning and evaluation of every aspect of the project. A foolproof formula for success does not seem to exist but the team can try and minimize the risk in the areas outlined that cause the most problems.

 

References

[1] Comelio, P. (2008). Why Do So Many Software Projects Fail?. Available: http://www.slideshare.net/PhilComelio/why-do-so-many-software-projects-fail-25nov2008. Last accessed 7th March 2014.

[2] Connell, C. (2010). Why Software Really Fails And What to Do About It.Available: http://www.drdobbs.com/architecture-and-design/why-software-really-fails-and-what-to-do/223700002. Last accessed 7th March 2014.

[3] Outspeaking. (2014). Why Do Government IT and Software Projects Fail?. Available: http://outspeaking.com/words-of-technology/why-do-government-it-and-software-projects-fail.html. Last accessed 7th March 2014.

 

Introduction

This is a response article to the blog post entitled; ‘Pair Programming: Will it make you hate your colleagues?’. The primary article analyses pros and cons of using pair programming 100% of the time spent working and concludes that while there are many benefits of this, it should be used in moderation as people can get aggravated if they have to work with someone else all of the time. In this post I will provide my opinions to the statements as put forth by the author and reach my own conclusion in regards to whether or not pair programming is always the right way forward.

 

Concept

This post explains what pair programming entails in a simple way. The concept and paradigms of working in this fashion are clearly stated.

However, I do believe that the roles of the two programmers are not limited to that of a driver and observer as described here. In practice, these roles will intertwine depending on skill and type of problem the two programmers are working on.

I also wish to comment on the description of the pairing permutation novice-expert as described in this section. I think it is important to include that even though this is a great way of training new employees, this should not be seen as a mentoring program. The purpose when pair programming in this fashion is so the novice can eventually hold enough skills to work alone or to be able to lead someone else.

In this section, the author also states that pair programming is most useful when ‘solving new, previously unseen problems’. I believe that pair programming is equally as useful when you are trying to increase quality without decrementing delivery time of the product.

 

Reaping the Benefits

In this section the author describes three key benefits of pair programming. The first being that even with novice-novice teams, productivity is increased. Quality of the code improves since it is being written/discussed by two not one. And finally, it is more efficient to review the code whilst it is being written and not only once it is complete. These are the most important and worthwhile advantages gained from this method, however I do believe it is important to outline the more subtle advantages to this system.

This includes the significant reduction of the risk of coding errors or bugs. The finished code will be much more readable and understandable since two people have had to comprehend what was written. This can also be a great exercise in team building and communication skills for the two involved.

 

100% Pair Programming: Yay or Nay?

Here the author discusses and analyses whether or not pair programming is the best idea for every single time code is written. Are there times when a lone programmer might do a better/faster job than if they had someone helping them?

The human factor issue is the first mentioned here however no argument is clearly formed. I would like to state that sometimes if employees do not get along or do not work well together, this could be seen as detrimental. However human and social interaction is an essential part of working in a team and I think pair programming could be a good way of forcing people to learn how to work well together.

The author discusses possible aggravation when it comes to design decisions when programming. These sorts of decisions would need to be made regardless of whether or not they are writing the code together or alone. Design is a constant in software development and I believe that the issues of design come before you start writing the code. Once they have been made, their implementation is what the pair-programmers must construct.

When the author describes the disadvantages of pair programming when doing mundane/trivial tasks, there are various aspects to this argument that have been left out. Firstly, who decides what is mundane and what is not? Something trivial for an expert may be hard and new for a novice. Pair programming in this instance would be extremely beneficial as a teaching tool. Although I do agree that this could sometimes be considered a waste of time, it might be useful in some circumstances.

 

The Bottom Line / Conclusion

The times when I have pair-programmed, either during projects or internships, I have always found it an extremely useful and educational method for writing code. This was especially due to the two of us usually possessing different skills so we could both contribute in different ways to the same problem. However, I have performed a lot of work alone, but with some form of support nearby should I have gotten stuck or made a mistake, which made a huge difference compared to being all on my own. Solving issues was much faster if I could simply ask someone nearby to have a look and help.

I therefore do agree with the final statement as concluded by the author. Pair programming is extremely beneficial. However there do exist times when programming alone is more advantageous than doing so with a pair, as long as you have some support should you need it.

 

References

[1] Extreme Programming. (2014). Pair Programming. Available: http://www.extremeprogramming.org/rules/pair.html. Last accessed 6th March 2014.

[2] Cockburn, A. Williams, L. (2014). The Cost and Benefits of Pair Programming. Available: http://www.cs.pomona.edu/classes/cs121/supp/williams_prpgm.pdf. Last accessed 6th March 2014.

[3] Evans, J. (2012). Pair Programming Considered Harmful. Available: http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/. Last accessed 6th March 2014.

Introduction 

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.

 

Summary

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.

 

Discussion

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.

 

Conclusion

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?

References

[1] Clark, A. Tools for Software Projects. Lecture slides, University of Edinburgh. Feb 2014 [Online]. Available: http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/Software_Tools_Lecture_Start

 

[2] Yeates, S. (2005). What Is Version Control? Why Is It Important For Due Diligence?. Available: http://oss-watch.ac.uk/resources/versioncontrol. Last accessed 4th Feb 2014.

 

[3] Nagele, C. (2013). Introduction to Version Control. Available: http://guides.beanstalkapp.com/version-control/intro-to-version-control.html. Last accessed 4th Feb 2014.

 

[4] Stansberry, G. (2008). 7 Version Control Systems Reviewed. Available: http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/. Last accessed 10th Feb 2014.