Sunday 26 January 2014

Continuous Integration in Agile Software Development

Question:

I am a fresher and have recently joined an IT firm as a .NET developer. After 15 days of orientation and training I am not part of a project team. I have been hearing a lot about Continuous Integration. Can you help me understand what it is and how does it help the project execution?

By: Rajesh Narayanan

Answer:

One of the important reason behind the software project failure was that the defects or issues discovered in the later phases proving to be too expensive to address and thus adding to the time and cost of the project. The industry has come up with different methodologies to address such issues and thus Agile Methodology has gained much adoption and recognition. As you may be aware, one of the key principles of Agile is to put in processes and techniques, so that the defects or issues are detected early on and thus giving opportunity to address sooner. Practices like SCRUM, Pair Programming, Test Driven Development are all expected to address this issue of catching the defects early on. On the same lines Continuous Integration and Deployment also contributes towards offering an opportunity to discover issues early on by offering the customer a working software product every now and then.

Traditionally, developers work on building components or modules independently and there will be a phase which will be fairly closer to UAT for integrating these modules together. No wonder, the development teams will discover many inconsistencies leading to the modules not working in tandem as intended. This calls for rework on one or more of the already built modules.

Continuous Integration addresses this problem by ensuring that every time the developer checks-in the code changes, the code modules are integrated with other related modules and deployed as well. This activity is best achieved by automating the build and deployment process. That means, the developer as he checks in code changes, will see the build and deployment errors and or warnings, which are expected to be resolved then and there, so that every code change that is checkedin does not break the working product. Thus the end customer will be able to see a working product always and able to validate the change as it is implemented.

The following are some of the key practices that makes the Continuous Integration workable and useful as well:


  • Maintain a Single Code Repository - Continuous Integration won't work if developers maintain isolated code repositories for different component or modules. There are plenty of open source and commercial source code control tools that offers robust conflict resolution techniques and facilitates usage of single code repository.
  • Build Automation - The Continuous build and deployment activity is best accomplished by automating the same. Most of the programming languages support this requirement and tools like CruiseControl are also very useful to accomplish this.
  • Test Automation - The automation process shall also execute the basic tests by itself. this where Test Drivent Development is in use. The developers, as they write code are also expected to create test scripts, so that these will also be executed during the automated build process.
  • Frequent Code Commits - The developers should commit the code more frequently and at the least every day. They should commit the code after every logical completion of a code change, so that the build does not break. This where, the Agile principles revolves around braking the coding tasks into smaller units, so that such tasks typically take 8 or 16 hours to complete.
  • Automated Deployment - Coupled with build automation, the code should also be deployed on to the test environment, so those involved in testing see the latest changes as soon as they are committed into the repository.


Hope the above explains the purpose and the principles of Continuous Integration. You can look up Martin Fowler's article on the subject to know more.

Thursday 16 January 2014

Essential Skills For an UI Architect

Question:

I have been working on designing and building web applications both for mobile and desktop and am getting exposed to related tools and languages as well. I want to further improve my skills and want to shape myself as an UI Architect in the longer term. I seek your advice and guidance on pursuing my career in that direction.

By: Rajkumar Krishnan

Answer:

Given that you have experience and exposure on UI design, it is natural to aspire for becoming an UI Architect. As you would know, the word Architect has larger significance and calls for certain abilities which go beyond the core UI design. If you take a closer look, UI implementation is one aspect and UI design is another aspect of it. As an UI developer, you would be implementing the designs created by someone else, who is good at visualizing the user experience. It is essential that the UI designer also have sound knowledge on various current and emerging tools and technologies, so as to come up with a design that is implementable. The UI Architect role is much wider which should have the broader skills on every other related aspects of the solution being designed. Here are some of the essential skills an UI Architect should be capable of:

Core Skills: The core skills that an UI Architect should be capable of include but not limited to the following:

  • Ability to comprehend and discover the goals of the target users, motivations, and the work and interaction patterns and come up with a design that is intuitive, responsive and usable.
  • Exposure and ability to comprehend the Product design skills are very essential as UI does not stand alone and it has to be a part of the product that is being built. The UI that the architect comes up with should go well with the product design principles and concepts.
  • Good understanding on the information architecture is also key for a good UI design. Afterall the UI is all about presenting information to the users using different colors, layouts, graphics etc. Without a good understanding of the information and the inter relationships of the underlying data, the UI architect is most likely to end up with a poor design.
  • Great deal of understanding on the behavioral aspects of the users would be key to come up with a usable UI.
  • Testing skills are equally essential without which the design that the UI Architect comes up may not be testable at all.
  • Ability to unlearn is another key skill that every architect should posses. If you are a developer and if you know certain specific tools or technology you will tend to come up with a design that suits the tools or technology that you know but there are quite many other tools and technology out there which can assist to implement even better designs. While it is important that the design is implementable, the Architect should also understand that there is nothing that is impossible and should have wide exposure on various other current and emerging technology out there.
  • Should have sound knowledge on the fundamentals of the multi-media, for instance, in-depth knowledge on the various image formats and attributes, the technical attributes of the screens of differing sizes as used in desktop PC, smartphones, etc.

Other Skills: The following are some of the other related skills that an UI Architect should have:

  • Should be open minded without bias and should be able to sketch the visual UIs on paper or on appropriate drawing tools.
  • Should have reasonable business skills which will help in enhancing the ability to understand the interactions between the product and the human users, the motivation and goals of the end users, etc.
  • Should have very good communication and language skills. Needless to say that the UI Architect should have the documentation and presentation skills as well.
  • Other soft skills that are relatively important for any role are active listening, interviewing, observation, collaboration and inter-personal team skills, etc.
  • Know the art of trade-off. i.e. in any design there will be conflicting attributes and the architect should be good at trading off one for the other. For example, if response time is a key attribute for you, you cannot afford to use fat image in your design. You should be able to balance and trade off certain attributes for the other.

You may work towards sharpening your skills in the above areas you can eventually look at becoming an UI / UX Architect in the longer term. Good luck with your career aspiration.