Certified Scrum Developer

http://www.scrumalliance.org/courses/20094497-agile-developer-skills-part-of-the-csd-curriculum
Run by Chet Hendrickson and Ron Jeffries

This class is taught by a Certified Scrum Trainer but is not a certification course.
This course is part of the Certified Scrum Developer (CSD) curriculum. Successful completion of this course fulfills the technical training requirement for becoming a CSD. Interested individuals, however, can attend this course outside the CSD track. The course material and trainers have been vetted and approved by the Scrum Alliance. Please contact the trainers directly for questions about registration, course material, or logistics.


Agile Developer Skills: Technical Practices from Extreme Programming

Scrum’s incremental-iterative approach to software development requires Development Teams to find, learn, and implement solid technical practices.  In recognition of this, the Scrum Alliance has created the Certified Scrum Developer program.  This course is the first to meet the Scrum Alliance requirements for training in support of the CSD rating. Frankly, we intend this course to be a benchmark of how to do this.

Jeff Sutherland, co-creator of Scrum, has said that the only hyper-productive teams he has seen have been using XP-style technical practices. This is no surprise: the practices shown below are practically essential to working in the Scrum style:

Participants in this course will experience the basic technical practices required to sustain a Scrum Project:

• Collaborative Software Development
• Test-Driven Development
• Acceptance Testing
• Simple Design
• Refactoring
• Continuous Integration
• Coding Standards/ Java Implementation Patterns

Using Java /Eclipse, thoughtfully crafted simulations, lecture, and discussion, we will build the strong technical foundation required to be a full member of a Scrum Development Team.

Course Prerequisites

• This course does not cover Scrum/Agile basics but if you are experienced in agile you should be OK. If in doubt, check with us.
• Working knowledge of Java and Eclipse.  This is a course for developers after all.
• A laptop with Java and Eclipse installed.  We will use pair-programming for all coding exercises, so even if you don’t have a laptop we will pair you with someone who does. If one, please plan to set up Java/Eclipse and bring it.

Course Logistics

Unless otherwise noted, we will provide drinks and snacks.  Check the registration page for the specific course you are interested in to see if a hotel discount is available.

Summary

Developers on Scrum teams, or on other forms of Agile teams, or who are interested in preparing to work on such teams, will benefit from this course. You will experience real team-based iterative development of software under the guidance of a Product Owner. You’ll get exposure to how to do the necessary and desirable practices, and some experience doing them.

The primary benefit of this course will be the learning. You will also have accomplished a necessary step to attaining the Certified Scrum Developer Rating.

Securing Java

http://www.securingjava.com/chapter-seven/chapter-seven-1.html

http://stackoverflow.com/questions/1935479/do-javas-inner-classes-pose-a-security-risk
This information is a around a decade out of date. The widespread use of anonymous inner classes with AccessController.doPrivileged should be a clue. (If you don't like the API, consider the proportion of try-finally blocks that are incorrectly missing in the JDK.)
The policy is that no two class can share the same package if they are loaded by different class loaders or have different certificates. For more protection, mark packages as sealed in the manifest of your jars. So, from a security standpoint, "Rule 4" is bogus

Sun's Secure Coding Guidelines for Java

http://java.sun.com/security/seccodeguide.html

ironic to see "Guideline 0-3 Avoid duplication" in above and yet
Duplicates abound in JDK 1.4 source code

Clean Code Tips

http://www.informit.com/promotions/promotion.aspx?promo=136914

Clean Code Tips

• Robert C. Martin’s Clean Code Tip of the Week #1: An Accidental Doppelgänger in Ruby
• Robert C. Martin's Clean Code Tip of the Week #2: The Inverse Scope Law of Function Names
• Robert C. Martin's Clean Code Tip of the Week #3: Avoid Inappropriate Information
• Robert C. Martin's Clean Code Tip of the Week #4: Avoid Obsolete Comments
• Robert C. Martin's Clean Code Tip of the Week #5: Avoid Redundant Comments
• Robert C. Martin's Clean Code Tip of the Week #6: Avoid Poorly Written Comments
• Robert C. Martin's Clean Code Tip of the Week #7: Clean up Old Commented Out Code
• Robert C. Martin's Clean Code Tip of the Week #8: Your Build Shouldn't Require More Than One Step
• Robert C. Martin's Clean Code Tip of the Week #9: One Step Test
• Robert C. Martin's Clean Code Tip of the Week #10: Avoid Too Many Arguments
• Robert C. Martin's Clean Code Tip of the Week #11: Output Arguments are Counterintuitive
• Robert C. Martin's Clean Code Tip #12: Eliminate Boolean Arguments

Crap4J

http://www.crap4j.org/

XP Practices

http://www.xprogramming.com/Practices/xpractices.htm

Commit Often

http://stackoverflow.com/questions/1286057/continuous-builds-and-agile-vs-commit-often

http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html

http://www.codinghorror.com/blog/2008/06/dont-go-dark.html

Alistair Cockburn: I Come to Bury Agile, Not to Praise It

http://www.infoq.com/presentations/cockburn-bury-not-praise-agile
Slides: http://alistair.cockburn.us/get/2754

What is software without analogies/metaphors?

• people making ideas concrete in an economic context

http://alistair.cockburn.us/The+Swamp+Game

Swamp Game
If you only have one round to play you just try and build it as quickly as possible, but if there's another round, the strategy changes.

Two Conflicting Goals

• Deliver this software
• Setup for the next game
• Refactoring, adding tests, junior devs -> senior devs

Project managers never happy, need to do more refactoring/tests

Inside the game only 3 moves

• Invent
• Decide
• Communicate

The situations don't (almost never) repeat... the terrains always changing, have to be alert

Communication/control strategies change when you add more people or criticality increases - the swamp changes underneath you.

Communication Effectiveness

Face-to-face is most effective (whiteboard)

Phone strips out visual cues

email strips out vocal infelections

Paper is least effective

Recorded video is better than paper

People issues determine speed of project

Craft - 

Software has discipline envy of engineering, engineering has discipline envy of physics

Craft - pay attention to skills and medium (language)

Crafts

• Deciding what to build (requirements)
• Managing (people and projects)
• Modeling
• Designing the external view
• Large-scale design (architecting)
• Fine-scale design (programming)
• changes every 5 years, need to reset yourself every 5 years
• Validating the work)

People Learn in 3 Stages (Kanban)

• Learn (Shu)
• start off by copying something
• run into it's limitations
• Collect Techniques (Ha)
• Invent / Blend Techniques (Ri)
• just do it
• I don't know, I'll make it up when we get there

3 pillars

Cooperative Game

Craft

Lean

Lean

Software Development similar to manufacturing if you consider unit of inventory = unvalidated decision

Users & Sponsors -> UI Designers / BAs -> Programmers -> Testers

Software Development has several correction loops

Manufacturing hates feedback - screws up your life

New work queue, rework queue

How do we manage the rework queue?  Fights for attention with new work queue

The programmers are the only ones who can get rid of their feedback loops (don't produce bugs: test first, regression tests, automated tests)

Aim for continuous flow

Windows Disk Usage Utilities

http://www.techsupportalert.com/best-free-disk-space-analyzer.htm

http://sourceforge.net/projects/windirstat/files/

http://www.uderzo.it/main_products/space_sniffer/download.html

http://www.mindgems.com/products/Folder-Size/Folder-Size.html

Agile Architecture

http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney#

"Agile is about knowing what changes to ignore"

Excel keyboard shortcuts

http://www.keyxl.com/aaa33ef/136/Microsoft-Excel-Software-keyboard-shortcuts.htm

Dependency Injection

http://en.wikipedia.org/wiki/Dependency_injection

Without the concept of dependency injection, a consumer who needs a particular service in order to accomplish a certain task would be responsible for handling the life-cycle (instantiating, opening and closing streams, disposing, etc.) of that service. Using the concept of dependency injection, however, the life-cycle of a service is handled by a dependency provider (typically a container) rather than the consumer. The consumer would thus only need a reference to an implementation of the service that it needed in order to accomplish the necessary task.

However, there should exist a definite reason for moving a dependency away from the object that needs it because doing so can complicate the code hierarchy to such an extent that its usage appears to be "magical".

Benefits:

• One benefit of using the dependency injection approach is the reduction of boilerplate code in the application objects since all work to initialize or setup dependencies is handled by a provider component
• Another benefit is that it offers configuration flexibility because alternative implementations of a given service can be used without recompiling code. This is useful in unit testing because it is easy to inject a fake implementation of a service into the object being tested by changing the configuration file.

Drawbacks:

• One drawback is that excessive or inappropriate use of dependency injection can make applications more complicated, harder to understand and more difficult to modify. Code that uses dependency injection can seem magical to some developers, since instantiation and initialization of objects is handled completely separately from the code that uses it. This separation can also result in problems that are hard to diagnose. Additionally, some dependency injection frameworks maintain verbose configuration files, requiring that a developer understand the configuration as well as the code in order to change it.
• Another drawback is that some IDEs might not be able to accurately analyze or refactor code when configuration is "invisible" to it. Some IDEs mitigate this problem by providing explicit support for various frameworks.

Manually-injected dependency

Refactoring the above example to use manual injection:

public class DefaultCarImpl implements Car {
    private Engine engine;
 
    public DefaultCarImpl(Engine engineImpl) {
        engine = engineImpl;
    }
 
    public float getSpeedInMPH() {
        return engine.getEngineRPM() * ...;
    }
 
    public void setPedalPressure(float pedalPressureInPounds) {
        engine.setFuelConsumptionRate(...);
    }
}
 
public class CarFactory {
    public static Car buildCar() {
        return new DefaultCarImpl(new DefaultEngineImpl());
    }
}
 
public class MyApplication {
    public static void main(String[] args) {
        Car car = CarFactory.buildCar();
        car.setPedalPressure(5);
        float speed = car.getSpeedInMPH();
    }
}

In the example above, the CarFactory class assembles a car and an engine together by injecting a particular engine implementation into a car. This moves the dependency management from the Car class into the CarFactory class. However, this still may not be enough abstraction for some applications.

Agile Adoption
You can do it yourself: http://www.targetprocess.com/blog/2010/04/going-agile-from-within.html


The problem is that this process is so slooow. It is inevitably slow, because all the mindset changes are slow, and you can’t speed them up greatly. My estimate is about 1 year as a minimum (no proof, sorry, just personal experience). You can’t absorb all the agile spirit in a shorter period of time (maybe some geniuses can, but they don’t need coaches anyway). I do believe that a good agile coach can speed up agile adoption, but not as greatly as often advertised.
OK, so changes are slow. It is absolutely required to manage the change over a long period of time. You can’t setup something, run it for a couple of iterations and leave. There is a high chance that development team will degrade and slip back to old-and-oh-so-known practices quite fast. It leads to several possible conclusions:

1. If you hire agile coach, it is better to have about 1 year contract.
2. If you hire agile coach for just 3-6 months, setup internal learning/change process as fast as possible.

The main idea of agile adoption is a paradigm shift. People should change their habits, rituals, working patterns and activities. It is SO hard! Some people just can’t accept it and leave the company. The goal of agile adoption is to change mindset of as many people as possible and let rock-hard minority go.
So why I personally don’t like the idea to hire someone who will teach us agile? It immediately puts our intelligence to question. Are we really not able to learn ourselves? Can’t we read some books, discuss them and try, for example, Scrum in a single dev. team? If we want to hire someone, to me it looks like we’ve already given up and can’t do anything cool without external help. It looks like we got exhausted and now need a power recharge. It is similar to an external CEO hired in a desperate attempt to save company.



http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/

10 Mistakes in Transitioning to Agile

http://www.drdobbs.com/architecture-and-design/193402902;jsessionid=TXIPPZDDXINUXQE1GHPSKH4ATMY32JVN

What not to do

Mistake 2: Go Fast to Go Fast

Do not take the time to get your group and other groups within your organization to understand agile development. Especially if you're also growing fast and creating new departments, do not slow down and throw them into the mix. For example, say you just established a new User Experience group. Before you even have time to define the new group's roles, throw them into the agile initiative.

Make sure you don't clearly define the terminology, such as the similarities and differences between use cases and user stories. This way, everybody will have a different idea of what is being created and that will contribute to the overall confusion.

scrum-burn-down-charts-tasks-or-stories

http://stackoverflow.com/questions/369493/scrum-burn-down-charts-tasks-or-stories

There are several ways to do burn down charts in Scrum.
Some people suggest using the story points of unfinished stories left as your burn down charts in Scrum.
Pro: Only finished stories lower the chart
Contra: Chart doesn't move down in the beginning and then rapidly falls off
Others suggest to use the number of tasks left
Pro: Chart will move down, you can see if it is above the finishing line
Contra: You could move down to say 10 tasks left (hard tasks) in the end, and still have not one story finished. You've failed because only finished strories are good for your product owner.
Is the solution to have both a points-of-not-finished-stories and a not-finished-task chart?


In my opinion, tracking tasks is a rather suboptimal approach to tracking. In my experience, a story seldom really is the sum of its tasks - and often, while implementing a story, I find that the task breakdown was suboptimal, anyway.

Mountain Goat
Sprint Backlog: http://www.mountaingoatsoftware.com/scrum/sprint-backlog

Technical Stories

http://agilesoftwaredevelopment.com/blog/jackmilunsky/technical-stories-are-they-included-backlog

• This type of story definitely doesn't belong on the product backlog but would be a perfect task that could exist on the Sprint backlog assuming you're tracking tasks. I am still in the Scrum camp on task breakdown as opposed to the XP folks who prefer to work just at the story level. If you're doing task level breakdown during the sprint planning meeting then this type of Story or work could exist on the Sprint Backlog as a task and the time associated with doing this can be tracked on the burndown. Most XP folks will say this is just micro-managing all over again.
• To quote Ron Jefferies: "Technical stories have been found to be an inferior idea by many practitioners who have tried both ways. I don't know of a single one who would go back.
• I suggest you decide how to handle this as a team and do what you (the team) think is best. I will state however that the XP folks appear to be the most progressive in forging new ground in agile efficiencies and techniques so watch what they say carefully and even consider what they say.
• March 28, 2010 by Maritza van den Heuvel
  
  
  • I'm the PO on a fairly complex enterprise-level server-client authoring tool in the e-learning industry. In our team, technical stories are kept on the backlog. We believe it's important that they should be, since it gives them visibility beyond just the technical team. Very often, if business is not aware of pressing technology needs, there will be no support to do them.
  • By having the stories on the backlog, I am making stakeholders and non-technical people aware that they have to pay the piper. Fast-delivered features are not free - there is always technical debt to pay off. And often, by prioritizing a particular technical story, it enables us to pre-empt support issues. And support issues can derail sprints, so the less of those we have to deal with, the better. The value in actually tackling the technical stories transparently, is really that we are protecting our other sprint goals and over time continuing to build in quality in the product.
  • But I don't prioritize technical stories on my own. I do this in conjunction with the Scrum Master and one or more technical leads to ensure that I get the complete picture.

Ron Jeffries
Extreme programming installed (By Ron Jeffries, Ann Anderson, Chet Hendrickson)

Don't break the circle - customers write cards, developers do them.  Where possible - and it usually is - you should solve this by relating the technical task back to a real customer need, and breaking it down into iteration-size bites.


Carlo Kruger
http://www.slideshare.net/ironicbuddha/writing-effective-user-stories-2688143
Technical Stories • Adding CI, optimising DB, upgrade to latest Oracle, etc. • Consider trying to write a user story so that you are forced to define the business value • No user facing functionality, e.g. Rating engine consumes some output • Consider writing as a user story with the engine as the user • e.g: As the rating engine, I want well formed CDR’s so that I can minimise error logging • Don’t hurt yourself trying to force it; sometimes it’s OK not to use the format • Be careful that these aren’t tasks that have been elevated to stories... 

Acceptance Testing

Wikipedia presents two different agile Acceptance Testing concepts:

• splitting out an Acceptance Test card that business customers, business analysts, testers and developers collaborate on
• functional testing of a user story by the software development team during the implementation phase as you go (XP).

• http://en.wikipedia.org/wiki/Acceptance_testing
• Acceptance Tests/Criterion (in Agile Software Development) are usually created by business customers and expressed in a business domain language. These are high level tests to test the completeness of a user story or stories 'played' during any sprint/iteration. These tests are created ideally through collaboration between business customers, business analysts, testers and developers, however the business customers (product owners) are the primary owners of these tests. As the user stories pass their acceptance criteria, the business owners can be sure of the fact that the developers are progressing in the right direction about how the application was envisaged to work and so it's essential that these tests include both business logic tests as well as UI validation elements (if need be).
  
  Acceptance test cards are ideally created during sprint planning or iteration planning meeting, before development begins so that the developers have a clear idea of what to develop. Sometimes (due to bad planning!) acceptance tests may span multiple stories (that are not implemented in the same sprint) and there are different ways to test them out during actual sprints. One popular technique is to mock external interfaces or data to mimick other stories which might not be played out during an iteration (as those stories may have been relatively lower business priority). A user story is not considered complete until the acceptance tests have passed.
  
  
• Acceptance testing in Extreme Programming
  
  Acceptance testing is a term used in agile software development methodologies, particularly Extreme Programming, referring to the functional testing of a user story by the software development team during the implementation phase.
  
  The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, whatever it takes to ensure the functionality works. Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release. A user story is not considered complete until it has passed its acceptance tests. This means that new acceptance tests must be created for each iteration or the development team will report zero progress.

Using Customer Tests to Drive Development: http://www.methodsandtools.com/archive/archive.php?id=23

A comment is an apology.

http://butunclebob.com/ArticleS.TimOttinger.ApologizeIncode

Code Reviews in Agile Teams

• http://blogs.atlassian.com/developer/2009/11/code_review_in_agile_teams_part_i.html
• Code review is even more important when a really junior developer joins a team. Senior developer don't have time to hand-hold the junior folks, since they need to be coding. That said, doing small but frequent code reviews of the junior developer's code is no big deal. The result? Senior developers can focus on writing code for most of the day and spend a 10-15 minutes a couple times per day to review the code changes by junior developers. The junior developers benefit from feedback, and the senior developers haven't lost valuable coding time.
• In the next instalment I'll share a few pieces of advice and precautions related to implementing code review in an agile team or company as a standard process. 
• http://blogs.atlassian.com/developer/2010/03/code_review_in_agile_teams_part_ii.html
• Keep it lightweight
• Don't force it
  Don't micro-manage
• Encourage asynchronous reviews
• Actively share interesting findings, constructs, design decisions via code review - be the champion
• Treat code review as yet another state in your project workflow
• Small and frequent over large and rare
• Concentrate on the code and conversation, not on the code review tool and its endless capabilities
• Do not include too many reviewers
• http://www.atlassian.com/software/crucible/learn/whitepaper.jsp
• Formality Spectrum (most formal first)
• Inspection: An inspection follows a well-defined procedure that includes six stages:
  planning, overview, individual preparation, inspection meeting, rework,
  and follow-up. Certain participants have assigned roles: author,
  moderator, reader, and recorder. The reviewers use work aids such as
  checklists of the types of defects commonly found in certain work
  products to carefully examine the work product for possible errors. Data
  collected is used to improve the organization’s inspection process and
  software engineering processes.
• Team Review: Team reviews are planned and structured but are less formal and less rigorous than inspections. The overview and follow-up inspection stages
  are typically omitted, and some participant roles may be combined. The
  author might lead a team review and the reader role is omitted. Instead,
  the moderator asks the reviewers if they have any issues on specific
  sections of the work product.
• Walkthrough: A walkthrough is an informal review in which the author of a work
  product describes it to a group of colleagues and solicits comments. The
  Author takes the dominant role; other specific review roles usually are not
  defined. Walkthroughs are informal because they typically do not follow
  a defined procedure, do not specify entry or exit criteria, require no
  reporting, and generate no metrics.
• Peer Deskcheck: During a peer deskcheck only one person besides the author examines the work product. A peer deskcheck can be fairly formal if the reviewer uses defect checklists, analysis methods, and standard record forms.
• Passaround: A multiple, concurrent peer deskcheck is called a passaround. The author delivers copies of the
• An effective code review support tool will include the following characteristics and capabilities:
• Make it easy to begin holding reviews.
• Impose a very low administrative burden.
• Notify participants of forthcoming reviews and review results.
• Easily collect review comments in context.
• Enable threaded discussions.
• Facilitate an established formal review process.
• Provide customizable metrics generation.
• Provide comprehensive reporting of review results.
• http://www.ambysoft.com/essays/whyAgileWorksFeedback.html
  
• Defect found via review or inspection costs more to fix than defect found via pair-programming
  

Questions I'm asking myself

Can you do Agile without XP?
No:

• http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
• But because Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design. Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt. Two or three years later, I get a call--or one of my colleagues does. "Changes take too long and cost too much!" I hear. "Teach us about test-driven development, or pairing, or acceptance testing!" By that time, fixing the real problems requires paying back a lot of technical debt, and could take years.  What frustrates me the most is that this situation is entirely avoidable. In a green-field environment, the solid agile engineering practices included in Extreme Programming pay for themselves within the first few months. Without XP's agile engineering practices, code quality and productivity asymptotically decreases over time. With them, productivity starts lower, but then it asymptotically increases. I can't prove it, but my sense is that the two curves cross at about the eight-week mark. Maybe sooner. Agile engineering practices aren't only important--they pay for themselves! Doing anything else is pure negligence... if you understand your options. Scrum is silent on the matter.
• I think this is very indicative of the desire among managers especially to want to believe in a process or formula, and to fail to recognise the comparitively massive impact of the quality of the people in the team on project outcomes.
  
  Basically, great developers tend to do good work, and bad developers tend to do poor work, and no process or methodology can fix that.
  
  The real problem that successive methodologies have tried to solve is that the majority of professional software developers don't actually know how to write good code.
  
  Scrum is just the latest competence substitute, and it understandably falls just as short as all its predecessors.
  
  Invest in the people, their skills and in helping them to exercise discipline and reward good habits. Sadly, it's not a quick fix, which is why most organisations don't bother.
  
  The missing ingredient from the Agile Manifesto is CRAFTSMANSHIP. It's like a whole bunch of musicians running around trying to look cool and talking about their "art" when the vast majority can't play a major scale. The problem is that teams adopt Agile before they've learned all the "hard skills" that the Agile founders like Kent Beck and Bob Martin take for granted, like OO design. But they talk about software development as if they've mastered it, when all they've really mastered is planning poker and how to run a retrospective. They still write poorly constructed, buggy and ummaintainable code. Because it takes years to learn how to write elegant, well-constructed and reliable code. And why waste years honing those skills when you can get Scrum Certified in a week?
  
  Sadly, all these apprentices don't know what they don't know and simply will not accept that they have much to learn (as do we all!)
  
  This is great timing, actually. I'm chairing a conference on Software Craftsmanship in London on Feb 26th. I hear more and more from people who are as frustrated as we all seem to be about this. Maybe our time has come? (Well, you never know...)
  
  Rant over.
  
  Jason Gorman 

• http://martinfowler.com/bliki/FlaccidScrum.html
• ...they haven't paid enough attention to the internal quality of their software. If you make that mistake you'll soon find your productivity dragged down because it's much harder to add new features than you'd like. You've taken on a crippling TechnicalDebt and your scrum has gone weak at the knees
• The scrum community needs to redouble its efforts to ensure that people understand the importance of strong technical practices. Certainly any kind of project review should include examining what kinds of technical practices are present. If you're involved or connected to such a project, make a fuss if the technical side is being neglected.
• ...it isn't methodologies that succeed or fail, it's teams that succeed or fail. Taking on a process can help a team raise it's game, but in the end it's the team that matters and carries the responsibility to do what works for them. I'm sure that the many Flaccid Scrum projects being run will harm Scrum's reputation, and probably the broader agile reputation as well.... Teams that fail will probably fail whatever methodology they mis-apply, teams that succeed will build their practices on good ideas and the scrum community's role is to spread these good ideas around widely.
• http://xprogramming.com/blog/2009/01/30/context-my-foot/
• Jeff Sutherland, co-inventor of Scrum, says he has never seen a Scrum team become hyper-productive without adopting the XP practices
• http://beingextreme.blogspot.com/ (Monday, December 12, 2005: Breakfast in NY with Ken Schwaber)
• Can you do Agile without XP? [yes, Scrum...but...]
• http://www.gnonug.org/Events/4634.aspx "Agile without XP = Delayed Fail"
• http://agilesoftwaredevelopment.com/blog/jackmilunsky/state-agile
  Scrum is a methodology and process that provides the mechanisms for teams to learn and adapt. Scrum however doesn't say much about the meaning of DONE and how to accomplish that. That's where XP comes in. XP has great practices around engineering discipline. It teaches us all about craftsmanship and producing quality work. I personally cannot see anyone practicing Scrum without at least some elements of the XP toolset. Be it pair programming, TDD, ruthless refactoring, emergent architectures etc.

Yes:

• http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html
•  Agilists don't understand the roots of Agile - Complex Adaptive Systems
• We are faced with a global armada of agilists who know absolutely nothing of complexity theory and game theory. Yes, they know words like emergence and self-organization, because everybody's using them. But do they know where those words came from? And do any of them know what a phase transition is? Or a fitness landscape? Or an adaptive walk? Or an attractor?
• Agility is about moving software projects to the area of complexity, right between order and chaos... If you don't adopt a properly balanced set of practices, including technical ones, trying to be agile can harm your organization by moving it to far, from the ordered to the chaotic regime. Some parts of the system (like quality) might go out of control.
• OK, now it's time to sit back, relax, and enjoy the comments section of this post. Actually no, I will not relax. There's still plenty of stuff to do. Like, for example, figuring out how to introduce those bloody XP practices in our organization. Because I believe that some of them could actually be quite useful for us as well.
• Comments: http://www.reddit.com/r/programming/comments/7vrev/the_decline_and_fall_of_agilists
• To blindly follow an approach in a mantric way (i.e. you will not practice agile without XP, you will not practice agile without XP, you will not practice agile without XP) is to simply ignore that agile itself will have to adapt and change as it adapts and changes the programming discipline. Adaptability is the key not only in agile development but in all programming. To approach it in a dogmatic way, whatever that dogma, is - in my view - to miss the whole point.

Can you do an Agile pilot with junior developers?
No:

• http://www.davenicolette.net/articles/when_2b_agile.html
• Boehm and Turner's assertion that Agile methods can only be applied successfully by senior developers is due for an update. When Agile methods were new, it surely required people who had enough experience to understand the potential benefits of adaptive development and to recognize and cope with the risks and obstacles. Once an organization has completed one or two initial projects using an elite team, it is appropriate to expand the capability for adaptive development by bringing in junior developers to pair with their experienced colleagues. The result is knowledge transfer in the context of real project delivery. In fact, this is just how we have built our internal Agile development group from its initial size of 6 people to its present size of 70. It's worth noting that a number of these have relatively little overall professional experience, yet every one of them is an effective Agile practitioner.

Can you separate the interdependent Agile development practices, introducing them one at a time in baby steps and not acrue Tech Debt?

• Common code ownership
• Refactoring (In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.)

Should you encourage Scrum without XP and watch it come to its knees in order to learn something or from the outset insist the team pay attention to the internal quality of the software?


What quality practices that currently "work" could be seen as waste but dropping them might introduce too much chaos?

• Code review system - temptation is to "just approve it" to get it out the door rather than deal with technical baggage
• Commit messages on work requests - discourages "commit often"

Potentially Painful Best Practice changes

• Javadoc - development burden that discourages refactoring, but is expected as opposed to self-documenting code
• Different code conventions to rest of organisation

Extreme Programming means "Disciplined Programming"

http://martinfowler.com/bliki/SemanticDiffusion.html
A word that sounds good may be more likely to suffer from semantic diffusion. 'Agile' sounds like something you'd certainly want to be, the antonyms of agile aren't at all appealing. Who would want to still be merely 1.0 of the web? Kent Beck noticed this effect and thus deliberately picked Extreme Programming as a name because it less inherently desirable: 'extreme' is often used as a pejorative.

Waste

The Waste of Defects
http://community.ative.dk/blogs/ative/archive/2007/01/29/The-Waste-of-Defects-_2D00_-Bugs-are-Stop_2D00_the_2D00_Line-Issues.aspx

Lean Principle #1 - Eliminate Waste
http://community.ative.dk/blogs/ative/archive/2007/01/18/Lean-Principle-Number-1-_2D00_-Eliminate-Waste.aspx

Technical Debt

Ward Cunningham

http://www.c2.com/cgi/wiki?TechnicalDebt

http://www.youtube.com/watch?v=pqeJFYwnkjE
Borrowing money is good... rushing software out the door to get some experience with it is a good idea, but of course you would eventually go back and as you learn things about the software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
Plenty of cases where people would rush software out the door and learn things but never put that learning back into the program... analogy = borrowing money thinking you never had to pay it back.  Eventually all your income goes to interest and your purchasing power goes to zero.
By the same token if you develop a program over a long period of time by adding features but never reoganise to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer, in other words the interest is total and you make zero progress.
A lot of bloggers have confused the metaphor to mean you can write code poorly with the intention of doing a good job later

Martin Fowler

http://martinfowler.com/bliki/TechnicalDebt.html

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Wikipedia

http://en.wikipedia.org/wiki/Technical_debt

Coding Horror

http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html

No matter how talented and smart the software developers, all these tiny deferments begin to add up and cumulatively weigh on the project, dragging it down.

I believe that accruing technical debt is unavoidable on any real software project. Sure, you refactor as you go, and incorporate improvements when you can -- but it's impossible to predict exactly how those key decisions you made early on in the project are going to play out. All you can do is roll with the punches, and budget some time into the schedule to periodically pay down your technical debt.

Steve McConnell

http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx

One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too. 

How do You Make an Organization's Debt Load More Visible?

One organization we've worked with maintains a debt list within its defect tracking system. Each time a debt is incurred, the tasks needed to pay off that debt are entered into the system along with an estimated effort and schedule. The debt backlog is then tracked, and any unresolved debt more than 90 days old is treated as critical.

Another organization maintains its debt list as part of its Scrum product backlog, with similar estimates of effort required to pay off each debt.

Either of these approaches can be used to increase visibility into the debt load and into the debt service work that needs to occur within or across release cycles. Each also provides a useful safeguard against accumulating the "credit card debt" of a mountain of tiny shortcuts mentioned earlier. You can simply tell the team, "If the shortcut you are considering taking is too minor to add to the debt-service defect list/product backlog, then it's too minor to make a difference; don't take that shortcut. We only want to take shortcuts that we can track and repair later." 

Object Mentor

http://blog.objectmentor.com/articles/2007/06/27/ledger-for-my-technical-debt

Fulhack

http://weakreference.blogspot.com/2007/06/fulhack-annotation-10.html

Annotation based hack reporting tool


Resharper
http://creedcultcode.blogspot.com/2008/04/tracking-technical-debt-in-resharper.html
// HACK, // TODO, // DEBT




Use Maven Taglist Plugin
http://mojo.codehaus.org/taglist-maven-plugin/
http://stackoverflow.com/questions/1989177/how-to-manage-todo-programming-stuff

Macker

Macker

http://innig.net/macker/

Macker is a build-time architectural rule checking utility for Java developers. It's meant to model the architectural ideals programmers always dream up for their projects, and then break -- it helps keep code clean and consistent. You can tailor a rules file to suit a specific project's structure, or write some general "good practice" rules for your code. Macker doesn't try to shove anybody else's rules down your throat; it's flexible, and writing a rules file is part of the development process for each unique project.


PMD

http://pmd.sourceforge.net/


PMD scans Java source code and looks for potential problems like:

• Possible bugs - empty try/catch/finally/switch statements
• Dead code - unused local variables, parameters and private methods
• Suboptimal code - wasteful String/StringBuffer usage
• Overcomplicated expressions - unnecessary if statements, for loops that could be while loops
• Duplicate code - copied/pasted code means copied/pasted bugs

Moving people around, Pairing

Move People Around:

http://www.extremeprogramming.org/rules/movepeople.html

Pair Programming:

http://www.extremeprogramming.org/rules/pair.html

Some fun pairing rules (guidelines) you can print out and stick on a wall maybe once people have tried pairing for a few weeks:

http://www.extremeprogramming.org/stories/pair.html

Some lessons you can probably only learn by trying it first and seeing what works in your environment:

http://www.extremeprogramming.org/stories/pair2.html

Dirty Secret
http://agilesoftwaredevelopment.com/blog/mendelt/dirty-secret-pair-programming

Ron Jeffries
http://www.xprogramming.com/Practices/PracPairs.html

Stability and Acyclic Dependencies Principle

http://www.objectmentor.com/resources/articles/stability.pdf


The dependency structure between packages must be a Directed Acyclic Graph (DAG). That is, there must be no cycles in the dependency structure.

Single Responsibility Principle

http://www.objectmentor.com/resources/articles/srp.pdf


The SRP is one of the simplest of the principle, and one of the hardest to get right. Conjoining
responsibilities is something that we do naturally. Finding and separating those
responsibilities from one another is much of what software design is really about. Indeed,
the rest of the principles we will discuss come back to this issue in one way or another.

Getters and Setters are evil

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html

Avoiding software rot

I think this web page is very relevant to where we are right now as a dev team: http://www.agile-process.org/change.html  (copied below with my emphasis) 

(agile-process.org has many pages well worth the read - it's the sort of site you want to come back and read every 6 months)

I think the key here is that if we're going to be agile, our codebase needs to be agile... i.e. easy to change

This means:

- code is always refactored - the next person doesn't have to tidy it up before they can begin

- code is fully tested (unit and acceptance) - so the next person doesn't have doubts about whether it works or not, they can re-design with confidence knowing the tests have got their back... And so we don't have bugs lurking around in dark areas of the code - bring it into the light!  Prove that it works!

- code follows conventions agreed on by the team - so the next person doesn't have to figure out why this code is different to the rest of the codebase

- there is no code duplication - we reuse code - rather than duplicating bugs / bad logic / unnecessary boilerplate code - we put it in one place so it can be easily changed

- code is simple - testable, understandable, browsable, explainable

Lots of good decisions in the small result in big payoffs in the large... lazy decisions in the small result in unmaintainable code... read on :)

Surprise! Software Rots!

Is software designed to be simple and elegant more valuable than software that is complex and hard to maintain? An Agile process accepts this as an important fact. It may surprise you to learn software rots. Intellectually we know it really doesn't, but it might as well. Software rot is caused by improper design and limited project resources. Complexity creeps in as easy code changes are made instead of difficult design changes. Code duplication accumulates rapidly during maintenance tasks. After a while we notice that fixing one bug causes several even more subtle (and expensive) bugs to occur and the cost of maintenance goes up significantly. Eventually the cost of maintenance exceeds resources. It seems as if our code has decayed on its own in spite of our best efforts. Berry Boehm found that as software proceeded through its life cycle the cost of making a change became larger. Ratios of 100:1 for making a change after delivery versus project start are common. But ratios as low as 5:1 can be found. How flat this curve stays depends on many individual project factors. This cost curve is commonly interpreted to mean that you must create infallible requirements documents followed by complete, detailed, and

error-free designs or pay a huge price later. That isn't what it means. Boehm's findings are not a condemnation of change but rather a caution tobe prepared when changes occur. A well run project keeps the cost of changes lower longer. There are three life cycle events that seem to accelerate software rot. When we proclaim the design is done and accept no more changes. When we move the system into maintenance and change the team's process. Last when the cost of making vital changes exceeds our resources we reach the wall of unmaintainability. To stay Agile you must fight software rot. Refactoring is the art of making design changes over time to keep the software fit for its purpose and ready for more changes. Unitand acceptance tests can almost eliminate the fear that drives inappropriate easy changes on a delivered

system. Early delivery of partial systems helps detect big changes before they become expensive. An Agile process accepts that requirements, analysis, and design are never truly done. An Agile process runs equally well in maintenance or development easing the transition. We know that some changes will cost much more than others. Boehm's findings were that 20% of the changes make up 80% of the effort. We accept that. We counter it with honest estimates and use a planning process that requires the customer to guide our spending decisions and cost compromises. We fight software rot from start to finish so it can never dominate our decisions. Agile processes are a re-evaluation of the way software is created. The quality of the source code is much more important than you may think. Just because customers don't see code doesn't mean we are excused from the effort needed to be ready for changes by keeping quality up, complexity down, and full test coverage.

Good vs. Great; Better vs. Best

http://blog.softwareontheside.com/2010/02/good-vs-great-better-vs-best.html

metaphors... (work in progress)

Asking me to add functionality to unrefactored, untested, potentially buggy code is like.... asking a craftsman to take shortcuts in his work.

Asking me to use a tool that is unfamiliar to me and I know is inferior is like...

Why Getters/Setters are evil

http://www.javaworld.com/cgi-bin/mailto/x_java.cgi?pagetosend=/export/home/httpd/javaworld/javaworld/jw-09-2003/jw-0905-toolbox.html&pagename=/javaworld/jw-09-2003/jw-0905-toolbox.html&pageurl=http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html&site=jw_core

Why extends is evil

Why extends is evil
Improve your code by replacing concrete base classes with interfaces

By Allen Holub, JavaWorld.com, 08/01/03

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html



I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

Losing flexibility
locks you into specific implementations, making down-the-line changes unnecessarily difficult.

coupling—the undesirable reliance of one part of a program on another part
"the fragile base-class problem" - Base classes are considered fragile because you can modify a base class in a seemingly safe way, but this new behavior, when inherited by the derived classes, might cause the derived classes to malfunction. You can't tell whether a base-class change is safe simply by examining the base class's methods in isolation; you must look at (and test) all derived classes as well. Moreover, you must check all code that uses both base-class and derived-class objects too, since this code might also be broken by the new behavior. A simple change to a key base class can render an entire program inoperable.
A better solution to the base-class issue is encapsulating the data structure instead of using inheritance.

Frameworks
an entire class framework that depends on derivation-based customization is brittle in the extreme

most of the Agile development methodologies (such as Crystal and extreme programming) simply won't work unless the code is written in the abstract.

If you examine the Gang of Four patterns closely, you'll see that many of them provide ways to eliminate implementation inheritance in favor of interface inheritance, and that's a common characteristic of most patterns. The significant fact is the one we started with: patterns are discovered, not invented. Patterns emerge when you look at well-written, easily maintainable working code. It's telling that so much of this well-written, easily maintainable code avoids implementation inheritance at all cost.

Domain Models

AnemicDomainModel
http://martinfowler.com/bliki/AnemicDomainModel.html
Anemic Domain Model anti-Pattern is a Domain Model that exposes only data and no logic.

An Introduction to Domain Driven Design

http://www.methodsandtools.com/archive/archive.php?id=97

Counter Perspectives...

Persistence Model
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/12/03/persistence-model-and-domain-anemia.aspx
A purposely anemic domain model - or not a domain model

Not convinced
http://opletayev.blogspot.com/2009/12/anemic-domain-model.html

Immutable objects are more efficient

Scala Creator Martin Odersky talks about immutability
http://www.artima.com/forums/flat.jsp?forum=276&thread=221233

[Stateful objects] used to be a shortcut for efficiency. You couldn't create new copies of objects because that was too expensive. But it actually has turned around, even for single-threaded code. If you change an object, modern garbage collectors have to do a thing called card marking, which is incredibly expensive. The more you change fields, particularly of old objects, your performance is going to suffer. So it turns out that it's actually better to have immutable objects.

Josh Bloch on ignoring Sun's Coding Conventions

http://web.archive.org/web/20041209210459/java.sun.com/developer/community/chat/JavaLive/2002/jl0212.html

Richard Martin: In item 29 you state that variables should be declared as close as possible to the place where they are actually used. This contradicts section 6.3 of the Java Code Conventions document which states that you should "Put declarations only at the beginning of blocks". Whilst I completely agree with your reasoning and much prefer the approach you recommend, I am confused as to the lack of a clear recommendation from Sun on this.

Josh Bloch: Bluntly put, I think the Code Conventions doc is wrong on this point. More generally, I wouldn't take that document too seriously. It is not actively maintained or used at Sun.

Four "harmful" Java idioms

http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html

Use a naming convention to distinguish three kinds of data, not two: local variables, fields, and method arguments. (disagree)

Prefer the package-by-feature style over package-by-layer. (interesting idea, practical?)

Prefer immutable objects over JavaBeans.(agree)

Order items in a class in terms of decreasing scope, with private items appearing last. (interesting idea, potentially confusing)

Referenced

• Code Complete by Steve McConnell
• Martin Odersky, the principal creator of Scala
• Josh Bloch

An Introduction to Domain Driven Design - Dan Haywood

An Introduction to Domain Driven Design - Dan Haywood

http://www.methodsandtools.com/archive/archive.php?id=97

Testing Paths

http://adam.goucher.ca/?p=399

• Happy Path – These are your positive tests. They provide good data, in the correct order, on the correct screens and will likely allow you to sign off on a good proportion of your requirements.
• Sad Path – As the name suggests, these are the opposite of happy tests. Your sad tests should cover all the validation and error handling (in all layers of your application). You are going to have to look at the code to know whether you have got all these conditions, though a coverage tool might help. Remember though, that coverage tools will tell you 100% if every line has been touched, not if every line has been touched by all ways.
• Evil Path – This is somewhat of an extension of sad tests, but they derive from people doing bad things to your application. XSS, SQL Injection, removing JS constraints, etc. fall into this category. Try to think like both the average DefCon presenter as well as a script kiddie. While the attacked might be more sophisticated from the former, the later are far more prevalent.
• Social Path – Things along this path are more specific and start to move away from looking at the software directly and into the larger system it is a part of. In these tests the attack vector (for lack of a better term now) is the system operator rather than the system itself. What sort of things could you get the operator to give to you that they are not supposed to, and is there a solution (hopefully a technical one, but procedural might have to do) available to address it?