The software perspective:
In the field of software development having worked with different teams in projects employing both these two methodologies; I thought it would be good to write a small blog on the different approaches these two techniques adopt to solve the conundrum of producing successful software.
My prospective comes from being a software developer and not the actual project manager; hence I WILL be heavily biased towards the development team.
A little background:
First off it must be pointed out that PRINCE2 is a project management framework; while agile methodologies deal more with the particle side of software life cycle; hence comparison between the two is slightly skewed pending on what you are comparing. The blog will examine at a high level the different philosophies used by each to develop software.
PRINCE2
PRINCE2 is an acronym for “PRojects IN Controlled Environments” (version 2). It is a generic project management methodology used for exercising control over a project by setting out the major components of a project. It has a definitive set of processes that should be followed and adhered accompanied by documentation.
Although it originated in IT although the current version makes no reference to IT and indeed it can be used for all sorts of projects. Heck you can even used it to plan your next shopping trip but I wouldn’t recommend it. At stated in the introduction this blog focuses on using PRINCE2 as a tool for delivering software. More can be found on PRINCE2 [Here1] [Here 2] and [Here 3]
Figure 1: Process workflow of a typical PRINCE2 project
AGILE
On the contrast agile software development refer to a group of software development methodologies principally based on iterative and incremental development. In agile, requirements and solutions evolve over time through collaboration; focus is given to frequent deployment with quick feedback loops over processes and tools such as those imposed by PRINCE projects. More can be found out about the philosophy of in the agile manifesto and other resources [Link 1] [Link2].
Figure 2: Process workflow of a typical agile project
The philosophies:
PRINCE2 takes a very process oriented approach to software development – as evidenced by the 7 processes. In many ways the conventional waterfall model is akin to this liner approach whereby components follow after another with documentation covering the each step. Therefore projects in PRINCE2 define what is to be produced before any work is performed backup by the business case.
In my view this leaner process oriented approach is indirect conflict with several key principles of agile development namely:
(1) Individuals and interactions over processes and tools
(2) Working software over comprehensive documentation
(3) Customer collaboration over contract negotiation
(4) Responding to change over following a plan
Agile methodologies emphasize on close collaboration between the development team and business experts using face-to-face communication rather than using a formal structured processes such as those employed by PRINCE2. The focus of agile techniques is on delivering frequent features that add value to the business and to provide quick feedback to on those features. There is no formal process that govern how the team operates, hence leaving the team to “self-organise” and craft the code and achieve its goals on its own. Documents aren’t created for the sake of documents.
From experience:
Creating software is dynamic and ever changing process. Quite often what you find is that end users don’t really know what they are looking for until they actually started using the product. What at the start of the project might seem as a ‘MUST HAVE’ feature might in the end up as a nice to have or even replaced by some other component altogether. Clients often don’t know what they want or need until they actually see working software.
Due to this dynamic nature of software making accurate design prediction at the start of the project becomes very hard and any predictions are usually unsurprisingly incorrect. Where the PRINCE2 approach fails in software development I believe is in the ‘big design up-front’ approach. The fact that every requirement of the system needs to be documented on the onset makes huge assumptions before any code is written. Any deviation from this original plan involves a heavy handed approach to keeping everything aligned*. PRINCE2 sees change as something to be minimised and managed rather than be recognised it as an integral part of the creative working software.
PRINCE2 approach works well if the software being developed is well define and the requirements are exact and certain not to vary widely during the project… having a processes to guide such development might not be such a bad idea. But in reality this isn’t the case; specing out the details of a complex project is very hard especially when new features and third part integration is involved.
One important point here to make is that while PRINCE2 has been applied to various industries for various size projects this cannot be said for agile progresses. (You wouldn’t build a nuclear sub on agile principles, would you?); having said that you might build a Toyota.
Due to this different philosophy these two approaches aim to tackle the creation of software in a totally different manner and at the moment I am an agilest… what’s your thought?
Welcome your comments/thoughts/improvements
Also look at:
To my mind the new version of Eclipse (Juno) seems to be running a little slower than Indego.
Here is a list of things you can try to enhance performance:
1) The standard; configuring the C:\eclipse\eclipse.ini to allocate more memory on start up.
–vmargs
-Xms512m
-Xmx1024m
2) Turn off any validators that you do not need. ‘HTML Syntax Validator’ is a big culprit.
Windows –> Preference –> Validators
3) Deactivate plug-ins that you don’t currently use. I’ve found the ADK particularly resource hungry.
Widows –> Preference –> Startup and Shutdown
I also found that using the latest JDK makes some difference.
Hope this helps; any other suggestions welcomed
Designed for humans, inspired by wireless charging
- 4.8″ screen – is a nice to have
- voice control – siri iPhone done before
- 4G support – not that exciting
- peer-to-peer connection – never going to use that
- Bluetooth and NFC (Near Field Communication) – comes as standard right
- Wireless charging – What! What’s that you say “wireless charging” now that should get your attention.
Yes the Samsung Galaxy S III comes with wireless charging (AKA inductive charging); a feature which I think should raise a few eyebrows. But hold off before you go buying; apparently the wireless kit won’t hit the shelves till sometime in September when we can all try cable-free changing.
Yes the Samsung Galaxy S III comes with wireless charging (AKA inductive charging); a feature which I think should raise a few eyebrows. But hold off before you go buying; apparently the wireless kit won’t hit the shelves till sometime in September when we can all try cable-free changing.
Wireless chaining will be the benchmark for future phones and other devices. Wouldn’t it be great that as soon as you enter the house your phone starts charging just in time for you to pick-up the phone on your night out fully loaded 
. Humans are lazy & any technology employed to make our lives easier is bound to succeed.
Beach time
But don’t go off hitting the beach just yet: the drawbacks
- Range: not far really
- TIME: it will take longer MUCH longer to charge the phone
- It will use more power hence a lot is wasted
- Even less compatibility then there is now wit cables
- Cost: Generally you would have to buy the changing kit separately and it won’t come cheap
- I don’t one can use the phone and charging at the same time wirelessly
Note: Inductive charging is nothing new; Palm Pre has this back in 2009 and GM already had this install in Chevy Volt back in June 2011. The technology is widely used in artificial hearts and other surgically implanted devices. Even Oreal B toothbrushes where using it back in the early 1990s but because of the drawback stated above it never really took off in mainstream markets; so let’s hope that Samsung don’t make a hash of it.
The key for me is; as always; is PORTABILITY; if this established (which at moment is unlikely) then there will be a huge boom in devices which support this type of inductive charging. All of the drawbacks stated above will be overcome in time but the sticking point will be portability. Images ALL your devices charging wirelessly from one hub… there a thought.
Whether you like tor not wireless charging will be the thing for the future and not just for mobile phones; think of every device that has a cable and cut it off.
What is Agile Software Dev (ASD)?
First let’s start with the basics: Dictionary definition of agile:
Something that is agile is “Characterized by quickness, lightness, and ease of movement; nimble.” i.e. able to change quickly and easily.
In software application development; ASD means to have processes in place that will allow software teams to react to changing requirements in a rapid way. A practitioner of agile can use different methodologies within several frameworks to “be” agile.
Agile Software Development’s guiding principle focuses on keeping code simple, testing often, and delivering bits of functionalities soon as they’re ready. The goal of ASD is to build upon small client-approved parts as the project progresses; that is as opposed to delivering one large application at the end of the project.
There are various methodologies that are collectively known as agile. They all promote the values of the agile manifesto and they are consistent with the above principles.
Some of the more known methodologies are:
- Adaptive Software Development
- Agile Data Methods
- Agile Modelling
- Agile Unified Process (UP)
- Crystal
- Dynamic Systems Development Method (DSDM)
- eXtreme Programming
- Feature-Driven Development (FDD)
- Lean Development
- Microsoft Solution Framework for Agile
- Six Sigma
- Scrum
- Test-Driven Development
Why Agile?
“— accept that the project’s goal is a moving target —“
There are many reasons to why software teams should consider agile processes for their development but the one reason that stands out the most for me is that writing formal project specs is hard, time consuming + never complete. There is a trail of thought which says …“software cannot be completely specified through documentation or a model” and I agree with this especially for large projects.
- …people don’t know and cannot completely visualize what the software should be like till they actually play with it
- … a document can have plenty of information, but real knowledge is hard to put on paper; complete, rigid specifications are never complete
- …communication is never perfect and correction through feedback loop is essential
- … accept that most project will have changing requirements that evolve over the project life span
Moreover agile development can be exciting and invigorating for software teams whereby they are not just working of specs. Collaboration with end users is generally one of the things I find most rewarding about the job.
Pillars of Agile:
- Early collaboration between all stakeholders
- Active user involvement throughout the project
- Clear vision of needs, solutions and value
- Capture requirements at a high level; user stories is beneficial + low cost.
- Focus on simple solutions rather than complex solutions with features that may or may not be used
- Don’t try to predict future features
- Develop small, incremental releases frequently
- Early delivery of “good enough” features better than “perfectly” with later on.
- Testing should be done continuously in parallel to development (test automation imperative) – test early and often
Migration to agile:
Over the years increasing development teams have started to adopt agile methods and there have been many success stores…
In reality, though, agile is not a magic bullet that will solve all software development issues in your projects.
Adoption of agile is a big decision that mustn’t be taken lightly regardless of the methodologies or techniques to be employed. Understand the dynamics and pillars of agile techniques is vital. (Cherry picking won’t cut-it).
Whichever technique chosen; time MUST be given to map out the correct infrastructure/procedures to be used before jumping into the agile bandwagon.
One last thing to point; getting management buy-in is very important as often that could the major stumbling block.
One of the fundamental activities of any software system design is establishing relationships between classes. The two fundamental ways to relate classes are inheritance and composition.
Quite often the most common approach to gain access to class members and methods of a class is to extend the class. This is mainly due to the fact when we are introduced OO programming one of the main themes that most people get very excited about is inheritance. But using extends without careful consideration could be costly. Quite often the relationship between your classes is more suited for composition (i.e. a “has-a” relationship).
I remember when I was creating a cards game application; I needed access to players object in the canvas and mechanically just extended the players. Composition in that instance would have the correct approach to choose.
| Inheritance: advantages | Inheritance: disadvantages |
| + Dynamic binding (i.e. allowing the JVM to decide at runtime which method implementation to invoke). When used in the right place the prime benefit of dynamic binding is that the code becomes much easier to change.
+ Polymorphism (capability of holding superclass or any of its subclasses) |
- Superclasses are considered to be “fragile”; incorrect use of extends and one little change to a superclass can ripple down and require changes in many other places in the application’s code. |
| Composition: advantages | Composition: disadvantages |
| + Provides stronger encapsulation because a change to a back-end class needn’t break any code that relies only on the front-end class. | - The explicit method-invocation forwarding (or delegation) MIGHT have a performance cost as compared to inheritance’s single invocation.
- The bigger downside is that is that it is not as light-weight in Java. |
To Summarize:
One thing to consider is that if your goal is code reuse think composition as it provides a better approach that yields easier-to-change code. Don’t use inheritance just to get code reuse. An important question to ask yourself when you think you have a “is-a” relationship is whether that “is-a” relationship will be constant throughout the lifetime of the application and, with luck, the lifecycle of the code.
In general, over the years I become to favour composition over inheritance. I’ve seen too many projects; some of my own; get incredibly and unnecessarily confusing due to complicated inheritance hierarchies so deep that will make your eyes water. However, there are some cases where inheritance simply makes more sense logically and programmatically. These are typically the cases where an object has been broken into so many subcomponents that it doesn’t make sense any more as an object itself.
Joshua Bloch Nugget: Design and document for inheritance or else prohibit it. When designing for inheritance you are committing FOREVER to the self-use patterns.
JavaScript dialogs (usual suspects)
You’ve undoubtedly seen them, used them, and most likely gotten annoyed by them but nevertheless dialogs are fundamental part of websites. They enable interactivity with the end user and so forth …
The usual suspects
alert(), confirm(), prompt()
To certain extent the built in standard JS dialogs can achieve a certain level of interactivity but they only go so far. For example if you want to give the end user a list of choices before a “confirm” such a task cannot be done with ordinary confirm() or even the prompt dialog.
Enter modal dialogs
Definition of a modal dialog as taken from Wikipedia
“A modal window is a child window that requires users to interact with it before they can return to operating the parent application, thus preventing the workflow on the application main window.”
What that means to me is a div or any other container element superimposed on the window using css z-index.
The z-index property gives HTML pages (normally two-dimensional) a third dimension; it was introduced in CSS 2.1 February 25, 2004 candidate recommendation. In addition to the horizontal and vertical positions, elements also have “z-axis” which allows them to lay on top of each other. An element with greater z-index will always appear in front of an element with a lower Z-index order.
The idea here is to “inactivate” all the elements in an html document and present a dialog which must be “processed” by the user before any other actions can be taken.
Creating modal dialog (easy guide)
The CSS
/* This is the holder element; any divs within this element will be superimpose in the page*/
#myElement
{
z-index: 100;
position: fixed;
left: 0;
top: 0;
width:100%;
height:100%;
}
Note: the positioning is required to ensure that this div covers the entire page.
The HTML
Step 1: Create the holder div
<div id="myElement "></div>
Step 2: Div that will contain the content
</pre> <div id="myElement "> <div>ANYTHING HERE HAS A GREATER INDEX </div> </div> <pre>
Example 1
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>JavaScript Modal Example 1</title>
<style type="text/css">
/* This is the hidden div*/
#confirmationOverlay
{
z-index: 1000;
background-color: #DBDBDB;
position: fixed;
left: 0;
top: 0;
width:100%;
height:100%;
}
#confirmationOverlay div
{
width:400px;
margin: 100px auto;
border:1px solid #000;
padding:15px;
text-align:center;
background-color:#FFF;
}
</style>
<script>
function proceed()
{
var element = document.getElementById('confirmationOverlay');
if (element != null)
{
element.style.display = (element.style.display == "none") ? "block" : "none";
}
}
</script>
</head>
<body>
<h1>Examle 1</h1>
<blockquote>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
<p><a href="#" onClick="proceed()"><img src="images/proceed.png" style="border: none;" /></a></p>
</blockquote>
<!-- This is a hidden div that will be toggled; thanks to z-index it will superimpose itself -->
<div id="confirmationOverlay" style="display:none;">
<div>
<p>Are you ready to check in...?</p>
<p>
<a href="#" onClick="proceed();"><img src="images/OK.png" style="border: none; width:100px; hieght:70px;" /></a>
<a href="#" onClick="proceed();"><img src="images/Cancel.png" style="border: none; width:100px; hieght:70px;" /></a>
</p>
<p id="loadingImg" style="display:none;"><img src="images/loading.gif" style="border: none;" /></p>
</div>
</div>
</body>
</html>
Example 2
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>JavaScript Modal Example 2</title>
<link rel="stylesheet" href="css/general.css" />
<script type="text/javascript" src="js/script.js" ></script>
</head>
<body>
<h1>Examle 2</h1>
<blockquote>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
<p><a href="#" onClick="proceed('confirmationOverlay')"><img src="images/proceed.png" style="border: none;" /></a></p>
</blockquote>
<!-- This is a hidden div that will be toggled; thanks to z-index it will superimpose itself -->
<div id="confirmationOverlay" style="display:none;">
<div>
<p>Are you ready to check in...?</p>
<p>
<a href="#" onClick="checkIn('loadingImg');"><img src="images/OK.png" style="border: none; width:100px; hieght:70px;" /></a>
<a href="#" onClick="cancel('confirmationOverlay');"><img src="images/Cancel.png" style="border: none; width:100px; hieght:70px;" /></a>
</p>
<p id="loadingImg" style="display:none;"><img src="images/loading.gif" style="border: none;" /></p>
</div>
</div>
</body>
</html>
/* This is the hidden div*/
#confirmationOverlay
{
z-index: 1000;
position: fixed;
left: 0;
top: 0;
width:100%;
height:100%;
}
#confirmationOverlay div
{
width:400px;
margin: 100px auto;
border:1px solid #000;
padding:15px;
text-align:center;
}
/* Text styling */
.confrimTxt
{
font-weight:normal;
font-variant:small-caps;
color:#000000;
letter-spacing:4pt;
word-spacing:10pt;
font-size:10px;
font-family:arial, helvetica, sans-serif;
line-height:1;
}
blockquote
{
display: block;
padding: 0 60px;
width: 350px;
}
blockquote:before, blockquote:after
{
color: #4AA02C;
display: block;
font-size: 700%;
width: 50px;
}
blockquote:before
{
content: '\201C';
height: 0px;
margin-left: -0.55em;
}
blockquote:after
{
content: '\201D';
height: 50px;
margin-top: -80px;
margin-left: 3.10em;
}
function proceed(id)
{
toggleDiv(id);
hideProgressImg();
}
function checkIn(id)
{
toggleDiv(id);
// Do checks, make AJAX call etc.
}
function cancel(id)
{
toggleDiv(id);
hideProgressImg();
}
function toggleDiv(id)
{
var element = document.getElementById(id);
if (element != null)
{
element.style.display = (element.style.display == "none") ? "block" : "none";
}
else
{
alert("Cannot find element with id:"+id);
}
}
function hideProgressImg()
{
document.getElementById('loadingImg').style.display = "none";
}
You got to love jQuery
You got to love jQuery. If you familiar with jQuery you won’t be surprised to know that modal functionality is already implemented for you in that fun packed library. There are plenty of very good tutorials that you can try out. With jQuery I found that once you get the hang of the fundamentals its plain sailing from there onwards.
This morning I was at a security seminar host by Oracle and I just wanted to talk about some of the interesting points raised.
To my surprise what I found that there are quite a few sites out there that haven’t even bothered to take basic steps to ensuring their site is secure. A lot of hackers still succeed with simple URL manipulation and directory traversal. Just goes to show RTFM of your server could save you a lot of headache.
Another common source of hacks was to use that hidden harmless backup files that nobody cares about. If you are used to UNIX systems you know that backed-up files end might end with ~. Well that’s another point of attack. Say for example you have a php file (user_account.php) with the frist few lines connects to the DB and the script goes on to return user information. Potentially the file could start with something like:
<?php
$dbhost = 'localhost';
$dbuser = 'root';
$dbpass = 'password';
$conn = mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql');
Calling the php file over the web server will return html and you won’t even know about the db connection but what happens if someone had left a backup of that file named user_account.php.bak? Or easily done if modified the file in VIM whereby it will create a backup called user_account.php~. Well calling either user_account.php~ or user_account.php.bak your web server won’t know how to render such requests and will default to plain text…. and voila DB code right there. Proper version control and basic web server configuration could easily prevent this.
The more interesting hacks involved XSS (abbreviation for Cross Site Scripting) and what it comes down to is properly escaping all forms fields that is including files uploads. Even better use a framework that does this for you (i.e. Struts output mechanisms such as <bean:write … >, or in <c:out … > use the default JSTL escapeXML=”true” attribute). The problem with XSS is that some genuine tool use that technique to embed valid scripts on clients machines; Google Analytics is one of them if am not mistaken.
Concluding the relative easy which one was able to infect a site was truly amazing and the advent of social networks the spread of these attack serve only to inflame the situation. Developers need to be educated and trained to prevent hacker exploit these basic techniques.
The second part of the seminar was a sales pitch so the less about that the better .
