Pair Programming and Mentoring: Which Comes First?

Is there a difference between Pair Programming and Mentoring? Yes. Pair Programming is one of the XP practices. http://www.extremeprogramming.org/rules/pair.html says “One thing pair programming is not is mentoring. A teacher-student relationship feels very different from two people working together as equals even if one has significantly more experience”.

In project organizations, mentoring is crucial. Think about inducting graduate trainees or fresh graduates into software projects. In this situation, in addition to an induction program, identification of mentors and investing in mentoring programs provide lot of value. Also think about experienced new joiners. They may need some mentoring. When mentoring sessions include hands-on coding and discussions on ‘code quality’ and ‘design quality’ team members get an opportunity to learn to write good quality code.

Pair Programming is not practiced in all Agile projects. It is a common practice in all XP teams. In many projects Pair Programming remains in the wish list. Pairing requires rapport, trust and excellent work relationship. One way to start pair programming is to start pairing from an hour to couple of hours per day. This can provide positive results.

Mentoring takes a different approach. Identifying the need for mentoring on a case-to-case basis has to be one of the top considerations in software projects. Mentoring (when required) cannot be ignored or forgotten. Mentoring is not sufficient to produce good quality code. Practices such as pair programming help a lot.

Above all self-review of code cannot be ignored. Programmers can start self-reviews in simple ways. All they have to do is to ensure that they can eliminate a fixed list of programming errors (say 20 to 25 things) through self-reviews. This, in my opinion is the first step in the journey to improve code quality. With these steps, practices such as pair programming or peer-reviews will yield better results.

Mentoring is a great opportunity to imbibe the importance of self-reviews and self-review checklists in teams. Also, it is a great mechanism to bond new team members into teams.

Understanding the importance of mentoring and investing in mentoring programs comes first. When you do this you will know how to (also when to) introduce appropriate engineering practices in software project teams.


Requirements Specification: The Weak Links



Most of us believe that Software Requirement Specification documents handed over to project teams enable them in designing, coding, testing and delivering the end product. We trust, in every project we get into, that the business analysts and user representatives collaborated well in order to create such documents. We must be positive and think optimistically. We must trust. We must believe. However, our positive thinking, trust and belief can take us only so far unless we do our homework right.

Yesterday, I was reading a paper titled, ‘What’s Wrong with Requirements Specification? An Analysis of the Fundamental Failings of Conventional Thinking about Software Requirements, and Some Suggestions for Getting it Right’ written by Tom Gilb. Tom is the author of nine books, and hundreds of papers on topics related to Software Engineering. He has been a keynote speaker at dozens of international conferences. He has delivered guest lecturers in universities all over the world.

In this paper, Tom has outlined ten key principles for creating successful requirements specification documents. He has provided very good examples to illustrate these principles. I found it very interesting as it helped me realize several weak links in the way we gather and specify requirements. Let me share a set of takeaways from Tom’s paper in this blog post. I encourage readers to download this paper (It is free! No registration required) and read it.

1) Check if requirements specification helps you understand the top level project objectives. Make sure that these objectives are not verbose and qualitative. They need to be detailed enough but fit into a single page. Tom says that a good first draft of the top ten critical objectives can be made in a day’s work assuming that the key management personnel are available for discussions.

The top level project objectives remain weak links if you are not able to translate these top level objectives into success criteria that can help you measure the success of your project.

2) Understand the value delivered to stakeholders by means of satisfying the specified requirements. More than the defined functionality or user stories, the value delivered is what counts. Traditionally, we are not used to considering value when we think about requirements specifications. The ability to prioritize requirements based on value delivery is critical. Product Owner (Scrum), Business Analysts, Marketing Managers, and Product Managers need to focus on this function. When you implement a requirement (or satisfy a requirement) validate if you are delivering value to stakeholders.

3) Quantify requirements. Qualitative descriptions or textual representation of requirements do not help. Quantification enables measurement. Measurement is necessary if you want to improve.

4) Specify the value you want to deliver to stakeholders clearly. Do not mix this up with how you want to achieve the value (the 'design').When you are able to specify your needs clearly, the solutions to your requirements will naturally follow. Do not let the solutions change your real needs.

5) Instead of focusing on each functionality, focus on system quality. Great products go to market because of this focus.

6) Make the specifications rich with several elements such as historical data, test data, scenarios, etc.

7) Inspections can help you improve the quality of requirements. So, consider Specification Quality Control (SQC).

Finally, requirements do change or evolve. If you spend lot of efforts in hardening all requirements in advance, it is probably a waste of energy. Embrace change!

When you read, Tom’s paper you will realize the weak links in the current state of creating Requirements Specifications. Also, you will get an opportunity to learn from his experience and thoughts!

Who Cares About Software Quality?



This blog is about my observation and interpretation on the keynote address, ‘The Future of Quality’, at Belgium Testing Days 2012 by Goranka Bjedov. A moment of discontent or restlessness in her professional life related to the state of the industry and engineering practices during 2008 triggered several events that culminated in a realization, ‘Quality is Dead’, in 2009. This is because there were (and are) software products and applications out there in the market. Most of them are buggy. Customers are end-users accept such products. Buggy products become a source of revenue as they fetch maintenance and upgrade fees. According to her, practitioners went wrong with the thought that testing is all about checking by means of executing tests and finding defects. She emphasized that testing is more than this and there are several dimensions to testing.

Her question “What happens when value of quality is less than the price of quality” triggered additional questions. Is functional testing adequate? Do we do too much of functional testing (and hence spend a lot)? Is that cost justified? Do end-users pay more and get less? She emphasized that it is imperative for testing teams to ensure that nothing escapes, to provide information about the current state of quality, and stop the release of bad products. It is possible when testers understand product quality. Testers have to carry the right purpose and approach to make this happen.

We have seen software malfunction and failures in many industries. Businesses have paid huge sums of money to settle related charges and court verdicts. The keynote included several examples.

With these facts in front of us, she introduced ‘Productivity Testing’. According to her 'Productivity Testing' is all testing that is focused on faster development. Its main purpose is preventing developers from checking in bad code, and allowing for changes to the code with certain "peace of mind".

Unit tests, micro-benchmarks, "sanity" tests, etc. are examples of Productivity Testing. According to her these are small, fast, cheap to write and maintain, analysis-free (when they fail, it is clear where and why), perfect for automation, fantastic for gaming the system, managers love them (code coverage, metrics), and "technical" (are we using mocks, fakes, doubles, or something else?).

In order to stress on Agility, she shared Brian Marick’s quote

"The lore of testing is full of people who spent weeks improving test automation libraries without ever, you know, quite getting around to automating any tests. The trick is to make improvements in small steps while simultaneously continuing to frequently deliver the business value that makes the project worth funding. There's a real skill to moving gradually and continuously and simultaneously toward several larger goals."

This keynote revealed or reemphasized points such as

1) There is no point in claiming the number of test cases executed or talking about the coverage or number of test cases automated or the types of tools and frameworks used unless we demonstrate that we do the right things to add value to stakeholders at regular intervals.

2) Customers do not want everything right in a product to begin with (unless the product is going to impact their lives or critical money). They want products faster. They want the base quality right. Everything else does not matter. They want products free (and are ready to pay for services and upgrades).

3) When you have the base functionalities in place, it is ok if you deal with bugs as and when you find them. That is how many products are sailing through their life cycle in our industry.

4) We do get into a denial mode and hide ourselves claiming that because of high complexity in products, we are in this state.

I liked the way she concluded. She hinted that the current state of quality is the consequence our thought process, practices and attitude. In order to make the future of quality brighter we must have to think what we can do better. We can reduce development efforts (and costs) by writing productivity tests. We can bring in quality by adding smart system tests in the right places. We must think performance, scalability, usability, and optimization (virtualization, cloud). Also we must understand the economics of software and demonstrate the value of our work (in dollar amounts) to stakeholders.

Publishing volumes of test standards and guidelines do not ensure positive results unless practitioners understand the basics and apply context specific practices.

I agree. Our industry is evolving. We have seen a small number of top notch products and services in this evolution. Our industry will continue to evolve. We will continue to see top notch products and services. Either directly or indirectly customers define what is acceptable and what is not. Keynotes and discussions like these make us stop, think and revalidate our beliefs. Testers (and everyone in project teams for that matter) can enable the delivery of high quality products. Customers can demand quality. When both entities accept the unacceptable, we will continue to see bad quality products, and bugs that result in litigations and huge penalties.

When I shared this blog with Goranka, she added the following points.

1. All paid work should be about creating value - either in the short or in the long term.

2. Created value can be demonstrated in multiple different ways - but being able to attach monetary amounts to the value of work performed is the hardest one to argue with or dismiss.

3. Quality does not have a linear relationship with value. Once good enough is reached, the rest is obtained with effort that could have been better spent elsewhere.

4. ‘What is good enough’ is determined by the customer and not by internal test or QA department.

Additional Links:

     Goranka Bjedov‘s Keynote Abstract and Bio

     Brian Marick’s ‘Two Forgotten Agile Values: Ease and Joy’

     Goranka’s Keynote at STANZ 2011 (Video)

Belgium Testing Days 2012

CPGT served to speakers at BTD 2012!

Last month (March 12-14) I was in Brussels for a speaking session at Belgium Testing Days (BTD) 2012! BTD is a confluence of international speakers and audience. BTD 2012 was not an exception. We had not only a great speaker lineup but also a striking list of topics. Overall it was a well-knit program! Thanks to the organizers!

Let me share some of the takeaways from BTD 2012 in this blog post based on the sessions I attended.

1) The testing community can no longer afford to do more and more of manual testing or functional test automation. Focus on specialized test such as performance testing, security testing, etc. are critical. Context-driven testing is the need of the hour.

2) Decision on release dates, product quality, release criteria are business decisions. Testers can do their job of providing right inputs to business. Testers are not the decision makers.

3) Partnership with development team is critical to success. Testing teams cannot afford to function in silos.

4) Consider multi-dimensional metrics to make sense. Standalone metrics don’t make sense for decision making.

5) Introducing ‘Test Assurance’ role in organization is valuable. This role requires ‘Testers’ to transform by means of acquiring additional skills.

6) Quality does not come from testing. Quality needs to be built into all life cycle activities. When we fail to do this, we start depending on ‘testing’ to provide us quality – this is a wrong notion.

7) Test engineers must understand regulatory compliance requirements and do adequate compliance testing and assurance. This can avoid business risks.

8) Software testing professionals need to plan their career. It is a self-initiated activity. No one external to you can tell you what you should do next or move you to the next level.

9) Testers can leverage open source tools to build great test frameworks and solutions.

10) Quality is critical. End users expect a certain level of quality in products. We cannot afford to ignore this fact.

The venue, refreshments and food in the conference were sumptuous. The dinner hosted by conference organizers for all speakers on 12th March was fabulous! The dessert, -  CPGT,  was impressive and delicious. Wondering what CPGT is?  It is Chocolate Parfait and Ginger Tiramisu. Yes. That is in the first picture!

Do you want to read more blogs on BTD 2012? Here you go!

1) Johanna Rothman's Blog
2) Lisa Crispin's Blog
3) Karen Johnson's Blog
4) Sigge Birgisson's Blog


If you post a blog on BTD 2012 or come across any new blogs on BTD 2012, pl let me know. I will add the link here.