Status Update

Fellow Blog readers,

I've been away from Tech4Mind for quite a while, and have not written any review for a long time.
This is mainly due to some important changes in my personal and professional life(s).

But do not go away yet!

Tech4Mind is still alive, with brand new content to come very soon!

I've already finished writing a new review about Agile Methodology and the Open Source world, and currently writing couple more about general computing, networking, and other virus threats.

There should be some minor changes coming soon too, about reorganizing the whole site, centering it more on the software approach topic, and maybe creating a new blog for anything related to general computing and advices...

In the meantime, please go and visit this new website http://www.verveearth.com/. It's a startup centered on bloggers, brought to us by Clayton Brown and his friends, with an entirely new way to surf the net. It shows spatial and geographic connections that a blog search engine could never reveal. And getting yours is as easy as a click!

Please feel free to leave your comments and advices.

Until soon,

D.A.

What is the optimal iteration length in Agile Projects ?

The recognition of the Agile methodology and approach as a software development processes has led to an increased popularity in iterative development, whether those teams go so far as being Agile or not. An important concern in implementing an iterative process is selecting how long your iteration will go for. Common recommendations and practices vary from a one-week iteration process (in Extreme Programming) to a month-long iteration (Scrum), while some Agile projects’ teams tend to use much longer iterations.

One of the advantages of short iterations is the availability of the first shippable features after a very short amount of time. It also keeps the team focused on the goals for the current iteration, and the tight learning feedback loop allows the developers for rapid discovery of new and often optimal solutions.

On the other side, the intensity of work needed to complete short iterations can be exhaustive, as clear and strategic thinking can be hard to get in the given time. Furthermore, the potential time spent in waiting for people or resources not part of the team will be likely to extent the duration of the iteration.

But too long an iteration may subvert the core motivation for iterative development and tend to increase the project’s risks.

Nevertheless, an experienced Agile team working on a highly exploratory phase of a project may benefit from a long iteration (i.e. around four-weeks). Indeed, this gives the team enough time to investigate and pursue more creative solutions than they may have time for with shorter iterations.

Conclusion

One of the main goals in selecting an iteration length is finding one that encourages everyone to work at a consistent pace throughout the iteration. If the iteration is too long, there’s a natural tendency to relax a bit at the start, which leads to panic and longer hours at the end of the iteration. One must strive to find an iteration duration that smoothes out these variations.

Once we determine the appropriate iteration length, we should stick with it. Agile teams will benefit greatly from having a rhythm to their projects. Any regular iteration length can indeed provide this rhythm. This does not mean that we are not allowed to experiment with a different iteration length in order to find the optimal one, but rather try to avoid bouncing among different lengths without good reason.

Limitations of User Stories

Concept

A user story is a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort needed to implement it. It is one of the primary development artefacts for Extreme Programming project teams.

User stories are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customer's terminology, without technical or developer oriented syntax.

Argument

One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications; the biggest difference is in the level of detail. User stories only provide enough detail to make a reasonable low risk estimate of how long the story will take to implement. When the time comes to implement the story, developers will go to the customer and receive a detailed description of the requirements face to face.

Another limitation of a user story is their dependency to acceptance tests. Indeed, these ensure that it is later possible to determine whether the goals have been fulfilled. Without them, user stories are likely subject to various interpretations, which make them hard to use as a basis for agreement. Thus, they may fail to serve as a form of reliable documentation of the system.

Also, user stories can be difficult to put in place on large projects involving many developers, due to its structure and timely breakdown (Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level). Besides, it relies on developers' competencies, both in interpretation and estimates.

Implementing user stories in a project also requires close and regular customer contact, as they are likely to be updated and modified throughout the project. In some cases, this may be difficult to achieve, not to mention any financial impact on the project's budget and the eventual unnecessary overhead.

Conclusion

Because user stories contain so little information, we need to flesh them out when we first work with them. During the estimation effort, it is common to list programming tasks required to implement the user story. When we start to working on implementation, we may decide to create some rough sketches of what we are going to build, like a screen mock-up or a UML activity diagram representing the relevant business logic. User stories are merely the starting point.

TEST DRIVEN DEVELOPEMENT – When to, When not to

Concept

Test Driven Development (TDD) is a lightweight programming methodology that emphasizes fast, incremental development and especially writing tests before writing code. Ideally these follow one another in cycles measured in minutes. TDD is one of the core practices of Extreme Programming (XP).

Functionality in TDD is added in very small chunks. Typically the first cycle will deal with quite simple cases. Once we have these very simple tests working, we add more functionality, a bit at a time.

It can be basically seen as a three-step approach: write test, write code, refactor.

Argument

Test Driven Development can be used as long as the specifications are clear enough to let us write tests that would the software’s compliance. From there on, we can start writing the software.

It can also be used with existing software projects, but this would not be necessarily easy. Indeed, the larger the software project, the larger will be the blocks of untested code at the core. We could just write a huge test to exercise the block of code, but again this will be time consuming, subject to fail, and is also against the TDD spirit.

A good practice would be to concentrate on using TDD with any new project code, and regularly refactoring what already exists, breaking it in smaller piece of code over a period of time.

The use and implementation of TDD also depends on the size of the project as said earlier. Indeed, because TDD emphasizes on flexibility and fast turnaround, it is mostly used in projects involving no more than a few dozen programmers.

Also before getting into the TDD process, people have to lean it. This depends upon the individual and the circumstances. Basically it is a matter of developing a new habit.
On the other hand, we might find that it's best to learn it with someone else. If you can pair off with someone experienced with TDD, this can be especially beneficial.

To conclude, some practitioners believe that TDD cannot be used in developing multi-threaded code, or where security is a key consideration. Some arguably disagree with both of these conclusions. For best results, of course, TDD relies upon good relations with the customer and well-conceived specifications.

Extreme Programming vs. Scrum

Concept

Extreme Programming is a discipline of agile software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they currently are in the development process, and to adjust the practices to their unique situation.

Scrum is an agile process that can be used to manage and control complex software and product development using iterative and incremental practices. It significantly increases productivity and reduces time to benefits while facilitating systems development.

Argument

XP is successful because it stresses customer satisfaction. The methodology is designed to deliver to the customer the software he needs when it is needed. It allows the developers to confidently respond to changing customer requirements, even late in the life cycle.
This methodology also emphasizes on team work. Indeed, Managers, customers, and developers are all part of a team dedicated to delivering software that meets quality requirements. Practices used include targeted unit testing, refactoring, small releases and use of spikes.

Scrum, on the other hand, enables the creation of self-organizing teams by encouraging verbal communication across all team members and across all areas involved in the project. One of the key principles of scrum is its recognition that “empirical” challenges cannot be addressed successfully in a traditional "process control" manner. Hence, scrum adopts an empirical approach - accepting that the problem cannot be fully understood or defined, and instead focusing on maximising the team's ability to respond to challenges using an agile approach. This process includes the use of product backlog, daily scrum meetings, sprint planning and backlog.

Even though both XP and Scrum are radically agile methods, and Scrum often uses methods and practices coming from XP, they differ in some points. In fact, XP seems to focus on team productivity (i.e. doing something the right way and as productively as possible). Scrum instead focuses more on doing the right thing, getting the Risk on Investment from building the 20% of the functionality that is necessary to get the value and maybe not building the rest.

Also, the XP approach emphasizes on estimations, like finely defined user stories, and to measure and improve these estimates.
Scrum keeps the requirements more extensive, more in general user terms analyzed during the iteration. Estimating is not as important as in XP. The team does what it can, and gets better at figuring out how much it can do each iteration as it learns each others skill sets, the business domain, and the technology - iteration by iteration. It cares more about delivering business value than having estimates, which become meaningless in a collaborative setting.

Interaction Design

System name: SmartDraw 2007

This application lets you create all types of graphics using a huge catalogue predefined templates. Even though the software addresses the pain point of having a template for a document when are willing to develop, it has some interaction design issues.

Interface Design flaws.

1. Scrolling down a document using the drop down tab on the right expands the document instead of actually scrolling it down.

2. Choosing to open a new document while working on another document actually freezes the interface, and it takes some time for it to be reloaded and displayed properly (we have to minimize the window, then maximize it again.)

Recommended changes:

These two interaction design flaws could be resolved by re-doing some product testing involving the developers in it, to let them know the issues to be resolved. A simpler interface design approach along with a more rigorous testing phase should effectively fix these issues

Critique

Windows Picture and Fax Viewer

Overview

Image viewer built in Windows XP that is capable to view basic picture formats.

Key weakness

The Image viewer is known to have difficulty rendering PNG (Portable Network Graphics) images correctly.

Root cause

Even though PNG images are acceptably displayed, it sometimes causes entire lines to not be rendered at a high zoom level, making it confusing when examining critical image data. This is most likely due to a poor implementation of the PNG compression algorithm.

Suggested improvements

1. Review the quality requirement in order to fix the file rendering problem
2. Re-implement the decompression algorithm with a quality and efficiency driven objectives (rather than poor and dashed off implementation)
3. Test the feature before finalizing it