Based on Toyota’s lean manufacturing, the same concepts apply to agile software development. They are:
- Partially Done Work: Work in Progress, e.g. Code not checked in, code not tested, test cases not executed, requirements analyzed but not developed, etc.
- Extra Features: features fully developed, tested and delivered to the end user, but was never used
- Relearning: Spending effort in learning something more than once because of loss of information. This loss occurs due to lengthy delays or task switching or handoffs.
- Handoffs: Passing a piece of information from one team member to another, which may cause loss or change in information. For example, communicating customer requirements from a customer representative to the analyst, then a team leader, and finally to a developer.
- Delays: These are time intervals in which one or more team members are idle waiting for input from another activity. For example, waiting for staffing in a project, approval processes, lengthy feedback loops, requirements gathering, etc.
- Task Switching: Interruptions during execution, which causes huge ineffectiveness in time usage, like switching focus or priorities, working on more than one thing at a time, serving multiple customers at a time, fixing issues while developing new features, etc.
- Defects: Defect waste is not only the time spent in testing and fixing the defect, but also the time it lies undetected, which causes subtle undetected issues in the operations at the customer site.
Use this in your retrospectives to gain insight and improve your team’s efficiency and productivity.
This is a summary of Robert C. Martin’s Clean Code book. Once that contains a lot of gems that will make a coder efficient and with more sleep.
Disclaimer: The below is not something I wrote; it was copied from here. I’m just adding it on my blog for personal reference. Thanks goes out to wojteklu for creating this summary!
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
- Keep configurable data at high levels.
- Prefer polymorphism to if/else or switch/case.
- Separate multi-threading code.
- Prevent over-configurability.
- Use dependency injection.
- Follow Law of Demeter. A class should know only its direct dependencies.
- Be consistent. If you do something a certain way, do all similar things in the same way.
- Use explanatory variables.
- Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
- Prefer dedicated value objects to primitive type.
- Avoid logical dependency. Don’t write methods which works correctly depending on something else in the same class.
- Avoid negative conditionals.
- Choose descriptive and unambiguous names.
- Make meaningful distinction.
- Use pronounceable names.
- Use searchable names.
- Replace magic numbers with named constants.
- Avoid encodings. Don’t append prefixes or type information.
- Do one thing.
- Use descriptive names.
- Prefer fewer arguments.
- Have no side effects.
- Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag.
- Always try to explain yourself in code.
- Don’t be redundant.
- Don’t add obvious noise.
- Don’t use closing brace comments.
- Don’t comment out code. Just remove.
- Use as explanation of intent.
- Use as clarification of code.
- Use as warning of consequences.
Source code structure
- Separate concepts vertically.
- Related code should appear vertically dense.
- Declare variables close to their usage.
- Dependent functions should be close.
- Similar functions should be close.
- Place functions in the downward direction.
- Keep lines short.
- Don’t use horizontal alignment.
- Use white space to associate related things and disassociate weakly related.
- Don’t break indentation.
Objects and data structures
- Hide internal structure.
- Prefer data structures.
- Avoid hybrids structures (half object and half data).
- Should be small.
- Do one thing.
- Small number of instance variables.
- Base class should know nothing about their derivatives.
- Better to have many functions than to pass some code into a function to select a behavior.
- Prefer non-static methods to static methods.
- One assert per test.
- Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
- Fragility. The software breaks in many places due to a single change.
- Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
- Needless Complexity.
- Needless Repetition.
- Opacity. The code is hard to understand.
If you encounter the error below with Java 6 on OS X, make sure you’re using Maven 3.2.5 or older.
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.security.AccessController.doPrivileged(Native Method)
If you use Homebrew on OS X and you come across the error below, just:
- $ rm -rf /usr/local/Cellar/maven
- $ brew install maven
- $ mvn -version
- That’s it!
$ brew install maven
==> Auto-updated Homebrew!
Updated 2 taps (caskroom/cask, caskroom/versions).
Warning: maven-3.5.0 already installed, it's just not linked.