Agile Google-style

http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places.

If you're in the habit of pre-announcing your software, then the general public usually wants a timeframe, which implies a date. This is, I think, one of the reasons Google tends not to pre-announce. They really do understand that you can't rush good cooking, you can't rush babies out, and you can't rush software development.

The difference is that Google isn't foolish enough or presumptuous enough to claim to know how long stuff should take. So the only company-wide dates I'm ever aware of are the ends of each quarter, because everyone's scrambling to get on that big launch screen and get the applause and gifts and bonuses and team trips and all the other good that comes of launching things with big impact at Google.

"How To Write Unmaintainable Code"

http://freeworld.thc.org/root/phun/unmaintain.html

Source Code Is A Liability, Not An Asset

http://blogs.msdn.com/elee/archive/2009/03/11/source-code-is-a-liability-not-an-asset.aspx
http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability

Don’t we spend our entire professional careers designing, writing, and testing code? That’s what we do, right? Well, no. What we actually do is deliver business value, or solutions to real-world problems, or however you want to state it. That’s why companies employ software developers. Source code is merely the necessary evil that’s required to create value. With few exceptions, source code itself is not a valuable commodity.

Tradeoffs

Tradeoffs: the better of two goods
have as little source code as possible vs well-written, maintainable code is often more verbose than dense, impenetrable code, but you should always favor maintainability

Tradeoffs: the lesser of two evils
...

False Economies
companies will happily spend multiple months of an employee’s time, at a true cost of at least $10,000 a month, counting benefits, office space, and the like, in order to avoid paying $1000 or even $500 to license a third-party software package that does the same thing

Edward Tufte One Day Seminar

http://codeliability.blogspot.com/2008/05/edward-tufte-one-day-seminar.html

Edward Tufte

quotes and general notes:

• Great designs are transparent
• Never segregate data by the mode of production.
• Show all the data, it provides credibility.
• We should be concerned with the quality of thought.
• Don't use lowest common denominator design or you will have an intellectual disaster.
• Tables out perform graphs for data less than 1000 points.
• Screens should be 95% content and 5% administrative debris (scrollbars, toolbars, etc.). Measure it.
• Design the surface first. Outside-In design. iPhone designed the hardware platform before the software. iPhone has one of the highest DPI of any consumer device.
• Don't provide an application solution.
• Leave the UI alone once it's done.
• There is no relationship between the amount of information and the ability to process. The human eye can process 10mbit/sec.
• Don't be an original. Steal a good design.
• Consider a "super graph". It unifies and relates the audience to the data or theme.
• Increase information throughput
• Examine how newspapers report data and clone it. Examine "Nature" magazine.
• Multivariant problems are the only interesting problems.
• Progress in technology is measured in resolution
• Don't use legends on graphs. Put the text on the line.
• Maximize content reasoning and minimize decoding
• "We want to be approximately right rather than absolutely wrong"
• Use Gill Sans Font
• Annotate everything

about presentations

• Show up early for your own presentation to meet people, to show a gracious gesture, and to hand out materials early.
• Use presentations as a review of the material distributed prior to the meeting. Maybe simply ask "Are there any questions?" and end the meeting.
• Use Power Point as a projector operating system
• Give out handouts before meeting - people can read 2x-4x times faster than you can talk.
• What is the problem?
• Who cares? the relevance
• The solution
• Have a summary
• Say you will answer questions when they are done reading
• Use sentences. No laundry lists of nouns. Sentences for you to think causally.
• Don't use bullet reveals.
• Practice in front of a friend or a video camera
• Turn off the video and listen to the audio
• Ask a trusted friend for criticisim
• Never begin with an all purpose joke
• Never apologize at the start of the presentation
• Stay out of the first person during the introduction
• Stay on content
• Finish early

Canoo WebTest

Download: http://webtest.canoo.com/webtest/manual/Downloads.html

Install: http://webtest.canoo.com/webtest/manual/install.html

Data Driven WebTest: http://opensource.basehaus.com/webtest/screencasts/data-driven-webtest.htm

Maven Integration: http://mguillem.wordpress.com/2009/04/30/webtest-with-groovy-maven-and-eclipse/

WebTest vs Selenium (2007): http://mguillem.wordpress.com/2007/10/29/webtest-vs-selenium-webtest-wins-13-5/

File Copy interview question, under-constrained

http://exold.com/article/stupid-interview-questions

http://www.kirit.com/Interview%20by%20under-constrained%20programming

To ESB or not to ESB

http://blog.mulesource.org/2009/07/to-esb-or-not-to-esb/

Software For Your Head

http://books.google.com.au/books?id=LgHHfzec33UC&pg=RA3-PA4&lpg=RA3-PA4&dq=%22greatness+cycle%22+pattern&source=bl&ots=qBRccvZGLj&sig=hyhc-X11pqdg7w3hZZyG8UIQCEY&hl=en&ei=6J9QSo-CL4H8sQPS-ejkDw&sa=X&oi=book_result&ct=result&resnum=1

Agile is Dead

http://agilesoftwaredevelopment.com/blog/janusz-gorycki/agile-dead

Abstraction is not always a good idea

http://www.infoq.com/articles/tilkov-rest-doubts

abstraction is not always a good idea. Web services take the approach of trying to hide many very different technologies under a single abstraction layer — but abstractions tend to leak. For example, there is a huge difference between sending a message via JMS or as an HTTP request. Trying to dumb widely different options down to their least common denominator serves no-one. An analogy would be to create a common abstraction that hides a relational database and a file system under a common API. Of course this is doable, but as soon as you address aspects such as querying, the abstraction turns into a problem.

Finally, as Mark Baker once coined: “Protocol independence is a bug, not a feature”. While this may seem strange at first, you need to consider that true protocol independence is impossible to achieve — you can only decide to depend on a different protocol that may or may not be on a different level. Depending on a widely accepted, officially standardized protocol such as HTTP is not really a problem. This is especially true if it is much more wide-spread and supported than the abstraction that tries to replace it.

The Open-Closed Principle

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

Bertrand Meyer gave us guidance as long ago as 1988 when he coined the now famous open-closed principle. To paraphrase him:
SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.)
SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.

Acceptance Testing from Requirements

http://concordion.org/
http://testing.thoughtworks.com/gettingmore



Testing Tools
http://herbertwu.wordpress.com/2009/05/19/quick-scan-of-freemostly-testing-tools/

Zealots, Greatness

http://blog.objectmentor.com/articles/2009/03/10/lets-hear-it-for-the-zealots

"Michael Feathers who wrote a book defining Legacy code as code without tests – hardly a moderate point of view"


Philip Schwarz about 2 hours later: @Uncle Bob You said: People who excel are, by definition, zealots. People who aren’t zealous, do not excel.
I can’t help quoting the following Pattern I read in Software for Your Head:

Pattern: The Greatness Cycle

Problem: Mediocrity

Solution: Smartness leads to greatness, via presence, integrity, conflict, and passion

Greatness is conceived in your intention to achieve at an appropriate scale; it is born in the application of integrity; it flourishes in your navigation of conflict; and it matures in the vitality of your passion.

The GreatnessCycle is an important group behavior cycle. It is simple to understand, but difficult to practice. Its phases are as follows:

1.Smart people are present no matter what they are doing. ...Smart people will exploit the fact that the deeper one’s presence in any given moment, the more valuable the moment.

2.Presence leads to integrity. ...A lack of integrity and the fullness of personal presence are mutually exclusive. That is, a high level of presence is always accompanied by a comparable level of integrity.

3.Integrity leads to conflict. ...Individual integrity doesn’t automatically bind together individuals, but those persons will deal forthrightly with the differences that arise. To do less whether to avoid a conflict, to gloss over it, or to deal with it surreptitiously is to lack integrity. The maintenance of integrity leads to conflict.

4.Conflict leads to passion. If you care enough to weather the direct, honest conflict with your colleagues that flows from your practice of integrity, then you must care a great deal indeed. The emotions you feel when issues you care about are threatened will intensify into passion. Conflict is catalyzed by caring, and summons passion.

5.Passion leads to greatness. Passionate living provides the power to do great things. Though it neither mandates nor guarantees it, passion always attends greatness.

From "Software for You Head":
http://books.google.com.au/books?id=LgHHfzec33UC&pg=RA3-PA4

Spring

Mastering Spring MVC: http://www.javaworld.com/javaworld/jw-04-2009/jw-04-springmvc.html?page=2

Unit testing your Spring-MVC applications: http://java.dzone.com/blogs/mrjohnsmart/2008/02/03/unit-testing-your-spring-mvc-a

Spring Framework Chapter 15. Integrating with other web frameworks: http://static.springframework.org/spring/docs/1.2.9/reference/webintegration.html

What do Spring releases contain?: http://www.techq.com/source/code/Spring/2.5.6/index.html

A Sense of Urgency

John Kotter – “the world's foremost authority on leadership and change”

Background

11 years ago, author discovered planned changes were not fully launched, failed, achieved over budget or implemented with great frustration in over 70% of situations analysed.

In cases where changes are successfully implemented, a common formula was used.

Question: “What is the single biggest error people make when they try to change?”

Answer: They did not create a high enough sense of urgency among enough people.

Why Urgency is Important

6 reasons:

1. Change is difficult if no urgency
   It all starts with urgency, if urgency not high enough & complacency not low enough, everything else difficult
2. Success breeds complacency
   Complacency much more common than we might think & very often invisible
3. False sense of urgency is prevalent
   Opposite of urgency is false sense of urgency. Just as prevalent as complacency, even more insidious. Equals lots of energized action, driven by anxiety, anger, frustration, unfocussed, frantic, dysfunctional, prevents people from exploiting key opportunities & addressing problems
4. Mistaking false urgency for real urgency
   frenzied action is not true urgency
5. False urgency and complacency can be transformed to true sense of urgency
6. Change is continuous
   Urgency increasingly important, change is shifting from episodic to continuous, need to create & sustain sense of urgency, strong sense of urgency is moving from an essential element in big change programs to an essential asset in general

Complacency

Complacency is “feeling of self-satisfaction”

Complacency stems from unconscious emotion that leads to us behaving in certain ways

Complacency is a product of success, real or perceived.

How do the complacent think?

· Never think they are complacent.

· Contend with the status quo.

How do the complacent behave?

· Do not look for opportunities or hazards

· Inward focused

False Sense of Urgency

Driven by anger and anxiety

· Anger due to failed attempts to change or when they think they are blamed for the current difficulties

· Anxiety because people worry for their jobs and career, family etc

Useful questions

1. Are critical issues delegated to consultants?
2. Do people have trouble scheduling meetings on important initiatives?
3. Do meetings end with no decisions about what must happen immediately?
4. Are discussions too internally-focused?
5. Do people spend long hours developing presentations, run between meetings and get exhausted?
6. Do people regularly blame others for problems instead of taking responsibility?
7. Does passive aggression exists i.e. “Oh was that due today? I wasn’t told”
8. Specific assignments not completed on time and/or with quality?

True Urgency

· Focuses on critical issues – Not agendas overstuffed with just important or trivial

· Driven by deep determination to win – Not by anxiety about losing

· Try to accomplish something important every day – Never leave 1000 miles in last week of race

· Think that action on critical issues is needed now

· Not “I must have that meeting” but “that meeting must accomplish something important”

· Not belief that all is well or it’s all a mess but world contains great opportunities & hazards

· Not feelings of contentment, anxiety, frustration, anger but gut-level determination to move, & win now

· Alert and proactive

· Search for effective ways to get info to right individual

· Cooperate energetically & responsively

· Find ways to launch smart initiatives

· Doesn’t produce burnout/stress coz it motivates people to relentlessly look for ways to rid selves of chores of little value

· People determined to move & win, now – don’t waste time or add stress with irrelevant or business as usual activities

· Provide leadership (at whatever level) needed to create & recreate urgency (asset)

Increasing True Urgency

Help Others (Including Bosses) to See the Problem

1 Strategy & 4 Tactics

Heart-Head Strategy

4 tactics:-

1. Bring the OUTSIDE REALITY-IN
2. Behave with URGENCY EVERY DAY
3. Find OPPORTUNITIES in CRISES
4. Deal with the NoNos

Heart-Head Strategy

Most often planned changes preceded by intellectual buy-in.

The problem is all head and no heart

Aim for the heart

“Great leaders win over the hearts & minds of others” – e.g. Martin Luther King “I have a dream...”

5 key characteristics

· Thoughtfully created human experiences

· Work on all senses – tell/show/smell

· Sensory experiences are powerful, compelling, surprising, dramatic – deeply influence emotions

· Information presented by someone with confidence, credibility, passion and conviction

· Not designed to create just any emotion – not converting contentment to fear or vice-versa

· Make people feel that the crisis = blessing in disguise

· Situation speaks for itself

· Don’t explain why/how you’re exposing them to a particular experience – Not covert or manipulative, just don’t say what doesn’t need to be said

· Experience to bridge the gap between what exists and what you want

· Lead us to raise our sights, to emotionally embrace goals beyond maintaining status quo to bridge gap between today’s reality & aspiration

How to engage heart in presentation

· People like humility not arrogance

· If people feel like “he’s one of us” (through jokes, stories) treat with less suspicion (which blocks communication)

· Stories with a little drama are enjoyed by our feelings & remembered longer

· Personal stories -> intimacy -> friends -> not trying to take advantage of us

· Awkwardness -> vulnerable -> less likely to attack our decisions/beliefs -> comfortable

Tactic 1 - Bring Outside-In

Reconnect internal reality with external opportunities and hazards

Bring in emotionally compelling data, people, video, sites, sounds

8 measures

1. Listen to customer-interfacing employees
2. Use video
3. Don’t shield people from troubling data
4. Redecorate
5. Send people out
6. Bring people in
7. Bring data “in”, the right way
8. Don’t create false sense of urgency

Tactic 2 - Behave with urgency everyday

· Never act content, anzious, or angry

· Demonstrate urgency in attitude, speech and actions (incl. Meetings, 1-on-1, interactions, memos, email) as visibly as possible to as many people as possible

· Delegate well

· Avoid activities that no longer adds value

· Avoid crowded appointment diary

· Management by walking around

· Urgent patience

Tactic 3 - Find Opportunity in Crises

· Always be alert to see if crises can be a friend in order to destroy complacency

· Some see crises as bad, some view them as opportunities

· Opportunities because of “burning platform”

· Use crisis to create urgency

· Proceed with caution since crises can be deadly – never be naive

· Beware of 4 dangerous mistakes

· Mistake 1: Assuming crisis will create sense of urgency

· Mistake 2: People feel manipulated

· Mistake 3: Waiting for a crisis to happen

· Mistake 4: Crises can bring disaster if not correctly managed

Tactic 4 – Deal with the NoNos

· Remove or neutralise all the relentless urgency-killers, people who are not sceptics but are determined to keep a group complacent or, if needed, to create destructive urgency

· Nonos are highly skilled urgency killers

· Every organisation has NoNos

· Never ignore the NoNos

· 3 ways to deal with NoNos

· Distraction

· Get rid of them

· Expose them

Conclusion

• Act with urgency everyday
• Avoid false sense of urgency
• Adopt heart-head strategy

Rule of 3rds - an Agile Agreement Approach

http://adjix.com/wipb

Mule, XML, how to Test Drive Configuration?

How do you test drive this XML?

http://www.mulesource.org/display/MULE2INTRO/Hello+World+Example

or more to the point how do you ensure 100% coverage of your wiring?

Cost of Change - Scott Ambler

http://www.agilemodeling.com/essays/costOfChange.htm

Great diagram demonstrating how pair programming catches problems a lot earlier than traditional system testing and is cheaper in the long run