Interesting links for 28th March 2011

Nilesh Gule No comments

Silverlight / WPF / WP 7

Windows Phone 7 part 8 using sensors : http://www.silverlightshow.net/items/Windows-Phone-7-Part-8-Using-Sensors.aspx
Jesse Liberty’s post on adding an application bar to windows phone 7 : http://jesseliberty.com/2011/03/22/adding-an-application-bar
Kunal Chaudhari on using Busy Indictor in Silverlight application : http://www.kunal-chowdhury.com/2010/05/how-to-work-with-silverlight.html
Paging records in Silverlight using PagedCollectionview : http://www.kunal-chowdhury.com/2010/12/paginating-records-in-silverlight.html
Part 1 of Producing and consuming OData in a Silverlight & Windows Phone 7 application : http://michaelcrump.net/archive/2011/03/24/producing-and-consuming-odata-in-a-silverlight-and-windows-phone.aspx
MVVM talk material from UK Tech days : http://blog.galasoft.ch/archive/2011/03/24/my-mvvm-talkrsquos-material-is-online-uktechdays.aspx

Agile

Getting your BA career on critical path : http://www.bridging-the-gap.com/getting-your-ba-career-path-on-the-critical-path
Still no silver bullets : http://www.estherderby.com/2011/03/still-no-silver-bullets.html
Don’t have meeting : http://agileanarchy.wordpress.com/2011/03/25/dont-have-meetings/
New found respect for Story Points : http://blog.agilebuddy.com/2011/03/new-found-respect-for-story-points.html
Speed to value : http://www.jimhighsmith.com/2011/03/24/speed-to-value/

Miscellaneous

Nice post by Rob Conery on when should a method be property : http://wekeroad.com/post/4069048840/when-should-a-method-be-a-property
Martin Fowlers views on certification : http://martinfowler.com/bliki/CertificationCompetenceCorrelation.html
20 Mix11 HTML5 and JavaScript session : http://www.elijahmanor.com/2011/03/20-mix11-html5-and-javascript-sessions.html

Pair Programming–Does it really work

Nilesh Gule Agile, Pair Programming 1 comment

Background

I have been a follower, admirer and advocate of pair programming for a long time. Every time I try to advocate the use of pair programming I come across few faces who raise their eye brows and I get an impression that they are thinking what a waste of time. But I believe that if you use pair programming judiciously it can be a great asset. Lets see why I tend to lean heavily in favor of pair programming.

Does pair programming really work

I came across pair programming as a term way back in 2002 or 2003 when I had attended a BDotNet user group meeting. There was a presentation by a person from ThoughtWorks. But it was not until late 2007 and early 2008 that I actually experienced it personally. While I was working with my previous employer, after joining they had sent me to UK to understand the Agile practices and to get familiarize with the team. I got to work closely with my counterparts in UK and learn new tools and technology while pairing up with them. Ever since then I have been a big time follower of pair programming.

It is a proven fact that two brains working on a problem are far better than individual attacking the same problem. It brings different perspectives to address the same problem. People are able to generate ideas by discussing different approaches. There is also the advantage that you need not have a separate code review because it automatically gets reviewed. There is also a shared understanding between two or more individuals related to the same piece of code. In an unfortunate event of bugs arising out of that piece of code potentially there are two people who can address it. This reduces the dependencies on individuals and serves the Agile principle of cross functional teams. Pair programming can help new members of the team learn the tricks of the trade much faster. The system and the domain knowledge can be shared much faster by pairing with experienced developers.

Imagine a situation where a senior member has very good systems and domain knowledge but is not very well versed with latest technology. Whereas a new team member is very good at technology. If these two individuals pair up they can complete the tasks much more faster compared to both of them doing it individually. In another situation two developers from different expertise can contribute to help each others expertise. like a database developer and a middle tier developer working together can improve the delivery of code.

Pair programming reduces the need for specialists in the teams. You can have people who know little bit of every technology and tool used within the project. Another advantage of this I see is that it helps people in moving across teams much more easier. You no longer have hardcore dependencies on one or two individuals. In an unfortunate event of somebody leaving the organization or contractor leaving after the contract period you no longer have people taking important knowledge with them. You also don’t need the so called knowledge transfer sessions or handover between different people. My personal experience says that these sessions are useless. The person giving the knowledge is more or less looking at finishing the session and moving on as quickly as possible while the person trying to acquire the knowledge might not have enough information of what is required.

One of my ex-colleague made a very important point regarding pair programming. He said when you pair with someone for any reason both the individuals have to benefit from it. There is no point in pairing just for the sake of it. If only one person in the pair keeps on working at the task and the other one just sits besides him then it doesn’t serve any purpose. That is why the ping pong or shifting the keyboards every now and then between both pairs is essential. It keeps both the people focused.

Many people turn down the suggestion to pair with others saying it reduces productivity. My personal experience says that it improves productivity. One thing I have experienced quite often is that while working individually you tend to get distracted a lot by a new email popping up in your mail box, a new text message alert appearing on the cell phone, a phone call or some one gossiping around your workstation. While you are pairing with some one these things can take a backseat you tend to concentrate a lot better.

There is a general feeling in Agile community that most of the production code has to written by a pair. I do believe that there is lot of value in doing so as it improves the quality of code by manifolds. But there can be situations where a particular team has been working on the same project for quite sometime, almost all members have sound domain and technical knowledge and there is very little benefit gained by pairing with other team members. in such scenario you can skip pair programming and revert to it only when a complex functionality is being developed.

In my previous project one of my colleague had suggested that any live issues or production bugs needs to be worked by a pair. I see a lot of value in doing that. If for whatever reason you were unable to do pair programming while developing a functionality, at least while fixing a production issue you can have more than one person trying to address it.

Along with improving the technical and functional skills, pairing also helps in improving the interpersonal skills. You can get the team to gel together. The communication improves drastically as a result of pairing. You don’t need lengthy emails and separate approvals for getting small routine things done. I have seen couple of teams who practiced pair programming work very well as a close knit unit.

Conclusion

I firmly believe that pair programming is a must when the team has got different levels of skillsets. As the gap decreases the amount of pairing can be reduced. Another technique which helps a lot is to swap pairs periodically. Instead of same people pairing up for long duration there can be a primary developer responsible for delivering a user story or a piece of functionality. While the development is in progress different people can pair up with this primary developer. The frequency can be anything like swap pairs daily or twice during the day or at a logical point. Lets say the story has UI to be implemented, service layer changes to be done, data access to be modified and database schema changes. All these changes can be performed by a primary developer and swapped at each point with a different partner. I hope you can realize the benefits of taking such an approach. To me pair programming is very fundamental to Agile and one of the most required tool for building a truly cross functional team. If some one says they are working on Agile and they have specialists in one area in their team I am afraid they are not truly Agile.

Pairing may not be limited just to developers itself. In a truly cross functional team you can have a developer and business analyst pairing together. You can have a business analyst and a a tester pairing together. You can have a developer and a tester pairing together. The possibilities are many. If you can collaborate among all these different aspects of software development you can very well imagine the overall impact on the quality of what is being developed and delivered to the customer.

I have experience the benefits of pair programming and would suggest people to try it out. I have learnt a lot from seniors and juniors with whom I have pair programmed whenever an opportunity presented itself. instead of reading 100 pages of book and understanding very little from it, it can be very helpful to spend 10 minutes with an experienced developer and get to learn most of it. I would like to hear about your experiences. In my personal experience pair programming really works.

Until next time Happy Programming Smile . May be I should be saying Pair Programming Smile Smile

Quality and Agile delivery

Nilesh Gule Agile No comments

Background

One of the salient feature of Agile development is the emphasis on quality software. The quality can be measured in various forms. But the most oblivious ones are the visible indicators like the time to market, number of bugs per iteration or release. These are the aspects that are related to delivering the product or the functionality to the customer. There is also another aspect related to the software craftsmanship which is the quality of the code that is being developed. Agile tries to manage the balance between the two. There are occasions when quality is bound to get lower due to various factors. Lets look at some of the factors which help in building the quality into Agile projects.

Different Factors which impact software quality

The working software at the end of the iteration is one of the best measure which helps to gauge the quality of the deliverable. The customer has a chance to look at the potentially shippable product and can accept or reject the features. The early feedback helps the development team to rectify any errors as early as possible.

Assuming that there are enough software matrices in place the quality of the code can also be validated by means of code coverage and unit tests. Also the automated functional tests can help the product owner or their representatives to help the development team with examples which simulate the real life data. All these things combined together can act as a wonderful suite of regression tests which can be run as part of the automated build.

In order for these things to run smoothly its of paramount importance that every building block of the team functions as expected. But contrary to all the books and article that we read over the internet the truth is that it rarely happens that way. In almost every software project you have ups and downs no matter which project methodology you are using. Fortunately beauty of Lean and Agile projects is that it allows us to inspect and adapt to the changing needs.

Assume a situation where development team is ahead of the business analysts team. There is a situation where during a particular iteration there are less user stories to develop because the business analysts are still writing the stories and development team has finished almost all their tasks. And during the subsequent iteration there are so many stories to finish that development team does not have enough resources to complete the task in time. In an ideal world you would expect the business analysts to be ready with a set of user stories ready for development and development team developing them. Because iterations are time boxed in nature, it can be a tight call sometimes when the deadline approaches and there are many things still to be delivered. It’s a tough call to make. Whether to drop certain features or to deliver all the features but with reduced quality. This is the call which the stakeholders need to take.

It’s a choice between getting a quality product with less number of features. Or knowing that the quality of the product might not be very good but all the features will be there for the showcase or demo or whatever terminology is used to demonstrate the working software to the end user. When we try to squeeze in time and deliver more features, more than the normal capacity of the team, the whole balance shifts. This was summarized very well by Jesse Fewell in one of the trainings that I attended where he said “You have night outs and long weekends, angry spouses, shorter testing cycles, unstable product and possibly a failed appraisal”.

This is bound to have negative impact on technical debt as well. In order to complete the job at hand in a shorter span of time people are bound to take shortcuts. This can lead into duplicated code being written and code smells start to appear. In the long run it can make it very difficult to make changes to the system. Instead of achieving the goal of delivering more features we might end up with more number of bugs. In an attempt to increase the quantity of deliverable we end up sacrificing the quality of the product. In worst case you might end up spending more time fixing bugs which result out of these faster developed features and delaying the overall release cycle.

I personally feel that the quality needs to be built right into the product. It can never be done afterwards. Many project managers and scrum masters take the risk of delivering more features to meet the deadlines and sometimes to meet the numbers which the higher management looks at. It can serve the short term goals. But think of it over a longer duration. Assume that this scenario continues for 3 or 4 iterations of two weeks each and you have two months of development over. All of a sudden you realize that integrating a new features takes almost a month because of various interdependencies and complexities that have raised due taking shortcuts.

If you think from a customer point of view and what is that they would like. In situation one you have a delay of one week because you did not compromise on the quality of product by delivering less number of features but whatever you deliver was all Done Done. Or situation two where you delivered everything the customer asked for but at the end not even one feature was completely Done and had to be reworked for the next iteration to get to the stage of Done. You can answer for yourself in which situation the customer will be more happy.

Conclusion

Isn’t Agile all about delivering value to the customers? I fail to understand many a times why do people violate this very basic principle of Agile that we need to deliver quality software. If we deliver quality software at the end of every iteration the quantity of what gets delivered will take care of itself. All the numbers in terms of velocity etc will also fall in place over a period of time. It might take time initially to get to a point of stability. But it enhances your chances of maintaining a sustainable pace and giving the stakeholders a confidence that on an average X number of story points will be delivered consistently. If a team is not able to maintain a sustainable pace it becomes difficult to gauge when the development of a particular product will be done. In my opinion after some time customers hardly remember how long you took to build a product but they will always remember how well you built it. As software craftsmen we should make it easier for customers to make changes to their systems. And for that to happen we have to build quality into the product right from day one. You can never built quality as an after thought.