Agile Development - Lean. Eliminate Waste

I am back from a nice vacation in Brazil and ready to write a little more about Agile development. Last article I gave a 30,000 feet view about Lean, today I am going to get one of the principles (Eliminate Waste) and get a little deeper.

Waste

What is waste in software development? I described that on my last post as "everything not adding value to the customer is considered waste. In other words: In software development, waste is anything that does not improve the quality of code, reduces the amount of time and effort it takes to produce code, or does not deliver business value to the customer. That is too generic.

On Poppendiek's book she describes complexity as a great candidate on promoting waste. "Complexity calcifies our code and causes it to turn brittle and break. The prescription for complexity in software development is simple: Write Less Code !!

Complexity

Just about any company that starts with a single technology is agile by definition. It can deliver and respond to the customer with easy. As the company grows and achieve success it starts to become slow, unresponsive. They have developed a complex code base, array of products and technologies. Unless they get complexity under control they will strangle what made them successful. The responsiveness, the agility.

The problem with complexity is that is does not grow linearly it does in a exponential fashion. Soon it starts to dominate all other costs in the software development process. Wise software development organizations place top priority on keeping the software clean, small and simple.

So, how to deal with complexity? Here are some food for thought

Justify Every Feature

The very first step on controlling complexity is limiting the features and functions that make to the software base. It is like a diet... you will be able to control your weight if you control what goes in your body. So, every feature that gets developed should pass to a rigorous evaluation and prove that it will create more economic value than the cost throughout the lyfecycle. Loading a software with a laundry list of feature is the lazy way to do marketing. Worse than that it is a recipe for disaster since the complexity will increase with useless features (not so valuable).

It takes guts to limit feature set but it mostly pays off. A company that delivers a product with just the right amount of features shows that it understands its customer.

Minimum Useful Feature Set

On agile the ideal approach do deliver software is dividing the product in small feature sets that immediately deliver value to the customer; and release these feature sets in descending order or importance. That way the customer can quickly start using the software. So, a minimum feature set is the one that helps the customer do a portion of its job faster.

From the sustainability point of view software developed on a incremental way is easier to maintain because incremental development can be sustained for the life time of the software. Of course other disciplines surrounds the incremental process and promotes the easy to change characteristics of the software. Refactoring supported by unit testing is one of them.

Don't Automate Complexity

Sometimes software companies solve complex problems by wrapping the existing process in a complex web of software. Never automate complexity. Understand the problem and simplify the process then, if necessary automate. In other words you domain the technology, you customer has the domain knowledge of the business. It is your job to simplify and automate (solve) that problem the simplest way possible.

What is Waste in Software development then?

Poppendieck define 7 wastes

Waste	Description
Partially Done Work	The inventory of software is partially done work. The objective is to move from the start of work on a system to integrated, tested, documented, deployable code in a single, rapid flow. The only way to accomplish this is to divide work in small batches, or interactions. Example of partial work is: uncoded documentation, unsynchronized code, untested code, undocumented code, undeployed code.
Extra Features	Waste in software is adding features that are not needed to get customer's current job done. If there isn't a clear and present economic need for the feature, it should not be developed.
Relearning	Rediscovering something we once knew and have forgotten is perhaps the best definition of "rework" in development. Knowledge needs to be captured and needs to be wide available to the development team. Another way to waste knowledge is to ignore the knowledge people bring to the workplace by failing to engage them in the development process. This is even more serious than loosing track of the knowledge generated. It is critical to leverage the knowledge of all workers by drawing on the experience that they have built up over time.
Handoffs	Passing knowledge in a strange science. You can document your architecture and give them to an engineer and most likely it will not be of much help. On the other hand if you sit with this person and be with him on the transfer, give him some pointers on some aspects of the software, testing, the history behind what was done, most likely, sooner your engineer will be able to ride by himself. This kind of knowledge is called tacit knowledge and it is very difficult to hand off using documentation. When a work is handed off a vast amount of tacit knowledge is left behind in the mind of the originator. If each handoff leaves 50% of the knowledge behind, 3 % of the whole knowledge is left after 5 handoffs. So, to minimize lost: Reduce the number of handoffs, Use design build teams (complete, cross-functional teams) so that people can teach each other how to ride the code. Use high bandwidth communication Release partial or preliminary work for consideration and feedback
Task Switching	Concentrate on one tasks at a time and finish it before switching to another task. Switching to a different task is not only distracting , it takes time and often detracts from the result of both tasks. Task switching time is waste.
Delays	Waiting for someone in order to have your work done is a big waste. That is why a process like scrum puts so much effort on maintaining the engineering unblocked. Again, communication plays a very important role on minimizing delays. Have your team collocated or collaboration tools that promotes open communication. Have your daily meeting and try to identify and correct any roadblock.
Defects	Every code base should include a set of mistake-proofing tests that do not let defects into the code, both at the unit testing level and acceptance level. Somehow software still finds devious ways to fail, so testing experts should start testing early and often to find as many of these unexpected errors as possible. Whenever a defect is found, a test should be created so that it can never happen again. A good agile team has an extremely low defect rate, because the primary focus is on mistake-proofing the code and making defects unusual. The secondary focus is on finding defects as early as possible and looking for ways to keep that kind of defect from recurring.

Conclusion

We touched several subjects related to waste in software development and the text is self explanatory. I personally put a lot of importance of the defect aspect of building software. If we could "easily" convince engineer and QA that testing first enhances development speed, mistake-proof the code and helps on refactoring our lives maintaining and enhancing the software would be much easier.

In addition applying acceptance and unit testing has a deeper meaning than just mistaking-proof the code. Acceptance tests are best when they constitute the design of the product and match the that design to the structure of the domain. Unit tests are best considered the design of the code; writing unit tests before writing code leads to simpler, more understandable and more testable code. These tests tell us exactly and in detail how we expect the code and the ultimate product to work. As such, they also constitute the best documentation of the system, documentation that is always current because the tests must always pass.

Reference

Implementing Lean Software Development - From concept to cash. Mary and Tom Poppendieck

Code Standard and its benefits

It is a fact of life -- developers like to write code in different styles. Show us code written by ten different developers and we can show you ten different coding styles. So why should we try to develop and enforce coding standards? – Nigel Cheshire and Richard Sharpe

Motivation

This week after coming back from vacation and reviewing some code I notice that although we, as a company, advocate code standards people still value “the so called speed” for code clarity and style.

That motivated me to write about the importance of code standard and the benefits the group gains if everyone adhered to it.

Introduction

Believe or not I still remember the time we programmed C in Unix and the pride we would take in knowing that we were the only ones to understand our own code (at least understand while we were working on it). Variables with obscure names (a1, c4, etc) added to the mystic of being a computer scientist.

Nowadays with the improvement of internet, communication, collaboration and other buzzwords that implies working together; code standards became a necessity; a tool to improve communication. The value is no longer in the mystic but code in such an elegant way that the code communicates.

So, why code standards? Code standards are important for many reasons. First and foremost, they specify a common format for source code and comments. This allows developers to easily share code, and the ideas expressed within the code and comments, between each other. Most importantly, a well designed standard will also detail how certain code should be written, not just how it look on screen.

More important than the reasons for having a standard is actually adhering to it consistently.  Having a coding standard documented and available means nothing if developers are not using it consistently.  If that becomes the case, it is no longer a coding standard, it has become a coding suggestion.  Worse yet are the developers that do not have a style or standard at all, and think that their lack of a style/standard IS a coding style/standard!

Style vs. Standard

It is important to differentiate between a style of coding and a standard. A code style specifies things like how you indent, tabs vs. spaces, use of “Hungarian” notation of names and variables, etc. A standard often includes a coding style, but goes beyond just hot to name a variable: it tells you how that variable should be treated and when it should (and should not be) used.

So it is clear that creating a standard is no easy task. Good news is that for us .NET programmers, the standard already exists and tools to enforce these standards are part of the Develop environment we use.

• StyleCop - StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project.
• FxCop or Microsoft code Analyses -FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines for Class Library Developers, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.

These tools tend to be a pain, initially, when the programmer has so many bad habits that he/she will spend more time fixing their mistakes than coding. But as you become familiar to the standard you start to create good habits and program to the standard.

I personally tend to create snippets, little tools that helps me even more to code to the standard. Nowadays I know exactly what StyleCop will complain if I do wrong.

So what are the benefits you gain by adhering to a standard?

Benefits for Developers

• The source code will be more comprehensive and will become more easy-to-maintain. As the programmers become familiar to the standard and use the supporting tools more and more they tend to program to the standard and produce better code.
• The uniform approach for solving problems will be handy because code standards documents reveal recommended methods that were tried and tested on early projects.
• Less communication between developers and managers will be needed because programmers will not ask anymore on the details of the specification document because the defaults are stated in the standard.
• Is common to the less experience programmer to re-invent the wheel. When there are coding standards, there is a big chance that particular problem is not really a new problem, but in fact, a solution may be documented before.

Benefits for the Quality Assurance Team

• Well documented coding standards will aid the creation of "Test Scripts". Having reviewed the source code and tested an application based on compliance to coding standards, it added strong direction to ensure quality of the software product.
• Of course the readability of code improves QA understanding of functionality what improves the creation of automation or test scripts.

Benefits for Program Managers

• It is important for the project managers to maintain and secure source code quality on their projects. Implementing coding standards could jumpstart this goal halfway to its realization.
• Repeated performance pitfalls could be avoided. It is a common case that a released software product could be less impressive when it comes to performance when the real data has been loaded in the new developed database application.
• Lesser man-hour consumption as the sum of all efforts implementing coding standards.

Adhering to Code Standard

As shown above adhering to a well designed code standard can give your software development an edge. The hard part is convincing developers to adhere to it. Often we hear from developers that adhering to a standard slows them down, the tool is too restrictive, standards take the “creativity” out of programming, etc.

It is understandable that in crunch time you could argue that. It is understandable but not excusable. Tools and techniques are out there to facilitate such techniques. Not adhering to it shows the lack of commitment and the desire to improve.

While I am not going to describe the various methods that can be used to achieve this goal, I will mention one: Accountability.

Accountability will generally cause developers to write better code.  If they wrote a bug, they should fix it.  If the bug would have been prevented by adhering to the standard, it should be brought to their attention.  The flip side of this is that they should be rewarded for writing good code.

The secret to code to a standard is to constantly use stylecop or other tools. You may be impacted initially but it will payoff for you and your team later.

Conclusion

Coding standards are being adopted by more and more development organizations. Estimates suggest that 80% of the total cost of a piece of software goes into maintenance, and not enough effort is being directed at ensuring that the quality is maintained during the development process. Further, development and Quality Assurance teams are spending too much time in code reviews, correcting coding standards violations that could be detected and in some cases corrected automatically.

Tool for code analyses and coding style are out there to help achieve this goals. The challenge is not in the technology but in educating developers on the benefits of adhering to it.