“A Conversation with Martin Fowler”

Bill Venners interviewed Martin Fowler back in 2002 that resulted in six part series filled with engineering wisdom to absorb.

Among the many exchanges was the following on flexibility that reinforces some principals I try (not always successfully) to put in practice:

Bill Venners: In Refactoring you write, “Before I used refactoring I always looked for flexible solutions. Because design changes were expensive, I would look to build a design that would stand up to changes I could forsee. The problem with building a flexible design is that flexibility costs.” What is the cost and what is the alternative?

Martin Fowler: The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity. If your guess about the flexibility needs of your software is correct, then you are ahead of the game. You’ve gained. But if you get it wrong, you’ve only added complexity that makes it more difficult to change your software. You’re obviously not getting the payback.

It’s not hard to guess wrong about flexibility needs. You can guess wrong if requirements change. What you think is a requirement for flexibility now may go away or change in the future. You can also guess wrong if you put extra code into the program to improve flexibility but you don’t get it quite right. You get more complexity without getting the flexibility you were after.

The alternative is to use the XP approach and not put the flexibility in at all. XP says, since most of the time we get it wrong, just don’t put the flexibility in there. Now if you can’t evolve your design safely, then that is a foolish route to take. But if you can evolve your design safely, it becomes quite a nice approach. In fact it becomes a self-reinforcing approach. If you strive to keep your design as simple as possible by avoiding speculative flexibility, then it’s easier to change the code because you have less complication to deal with. The code is easier to understand and easier to change. As a result, you can make changes much more quickly.

Read the whole series:

Refactoring with Martin Fowler

Design Principles and Code Ownership

Evolutionary Design

Flexibility and Complexity

Test-Driven Development

Tuning Performance and Process

A great description of the bug elimination process

John Graham: “A bad workman blames his tools”:

1. Find the smallest possible test case that tickles the bug. The aim is to find the smallest and fastest way to reproduce the bug reliably. With heisenbugs this can be hard, but even a fast way to reproduce it some percentage of the time is valuable.

2. Automate that test case. It’s best if the test case can be automated so that it can be run again and again. This also means that the test case can become part of your program’s test suite once the bug is eliminated. This’ll stop it coming back.

3. Debug until you find the root cause. The root cause is vital. Unless you fully understand why the bug occurred you can’t be sure that you’ve actually fixed it. It’s very easy to get fooled with heisenbugs into thinking that you’ve eliminated them, when all you’ve done is covered them up.

4. Fix it and verify using #2.

Read the entire piece.

The secret of achievement is persistence – a ‘growth mindset’ over a ‘fixed mindset’

Wow does this headline sounds like so much self-help crap! But read the stories linked with an open mind. The research is thought provoking and inspiring.

Stanford Psychology professor and author of “Mindset: The New Psychology of Success”, Carol Dweck has spent decades researching the question “What makes a really capable child give up in the face of failure, where other children may be motivated by the failure?”.

Her research and a body inspired from it has implications for how we raise our children, how we manage employees, how we work to overcome difficulties, how we think of ourselves.

In April 2007 Stanford Magazine wrote up a profile of her titled, “The Effort Effect”.

Po Bronson referenced her work in a well-linked NY Magazine piece, “The Power (and Peril) of Praising Your Kids”.

That Bronson’s piece came out in 2007 and it influenced what I’ve come to believe about instilling a belief in Emma that she or me isn’t ‘smart’ – but that it’s smart to try and try again to figure something out, to learn something by practice and experimentation.

Dweck believes that we tend to have one of two mindsets when it comes to seeing achievement in others and ourselves: a ‘fixed’ mindset that tells us when we see someone’s mastery over something it is from innate talent, or a ‘growth’ mindset that tells us that person must have worked hard to achieve it.

People who believe others are born with certain talents tend to do worst than those that believe we can grow and change.

In order to believe someone can grow and change, including ourselves, we need to believe that failures have lessons and that if we keep at something, we can improve.

Just keeping that as a core belief can make all the difference in our lives and in how we see others. It calls on us to give ourselves a chance, to give others a chance. To be empathetic, to empower. And to keep on keepin’ on. This may sound a bit too ‘new agey’. But its more a call to action. Because yes, the world isn’t fair, but if we try and try again, we might raise our lives to a better place, and better yet, the lives of those around us.

Related:

Recently Po Bronson has co-authored with Ashley Merryman a new book I’ve been meaning to read that incorporates some of these lessons in parenting.

Science Daily 12/10/2009: First Evidence of Brain Rewiring in Children: Reading Remediation Positively Alters Brain Tissue

NPR: 12/9/2009: Reading Practice Can Strengthen Brain ‘Highways’

Nurture Shock: Po Bronson and Ashley Merryman: 12/10/09: New Research: $13 Christmas gifts = 13 point gain in kids’ IQ

The Atlantic: David Dobbs: December 2009: The Science of Success

“Genius is nothing more nor less than childhood recovered at will.” | MetaFilter

Can’t get it out of my head: A father’s yearlong quest to grasp the infant musical mind

TED.com: Video: “Martin Seligman on positive psychology”

New Yorker: Malcolm Gladwell: “GETTING OVER IT: The Man in the Gray Flannel Suit put the war behind him. Why can’t we?”

Finally, quote from Calvin Coolidge I’ve kept in my wallet for over 10 years:

“Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination are omnipotent. The slogan press on has solved and always will solve the problems of the human race.”

Rafe Colburn’s vote for Software Engineering’s “Trend of the Decade”

Check out Rafe’s thoughts on what he considers software engineering’s “Trend of the Decade”, Decentralized Process: More work done in public, public discussion of that work, and the introduction of new best practices have defined the trend of the decade — developers owning the processes under which they work. Hopefully it will continue in the next decade.

My perspective and experience says he’s right. And I gotta agree with his wish. Read the full post.

Some light reading (and research) on non-functional requirements in Agile/Scrum

Agile Modeling: Introduction to User Stories

Mike Cohn’s Blog: Non-functional Requirements as User Stories

aqris: Representing non-functional requirements with user stories

wikiwiki: Non Functional Requirements

Agile Coaching: Non-Functional Requirements: are user stories useful?

Artima: Johan Peeters: Dreams and Nightmares

Representing non-functional requirements is tricky. There are two kinds of non-functional requirement as mentioned in the aquis piece: independent, and distributed. When faced with a distributed non-functional requirement, adding it to your ‘definition of done‘ is called for. As you can tell by the links, there seems to be some difference in opinion in handling ‘independent’ non-functional requirements.

If you have pointers, please share in my comments. And thanks for the input in advance.

A solution to software maintenance from long ago?

Communications of the ACM: You Don’t Know Jack About Software Maintenance:

Software maintenance is not like hardware maintenance, which is the return of the item to its original state. Software maintenance involves moving an item away from its original state. It encompasses all activities associated with the process of changing software. That includes everything associated with “bug fixes,” functional and performance enhancements, providing backward compatibility, updating its algorithm, covering up hardware errors, creating user-interface access methods, and other cosmetic changes.

In software, adding a six-lane automobile expressway to a railroad bridge is considered maintenance–and it would be particularly valuable if you could do it without stopping the train traffic.

Related: Slashdot thread

Research: Software development roles and responsibilities

Trying to answer the elusive questions of:

What is a Software engineer?

What is a Lead Programmer?

What is a Tech Lead?

What is a Principal Engineer?

What is a Software Architect?

What is a Technical Project Manger?

What is a Scrum Master?

Links:

Wikipedia: Lead programmer

Wikipedia: Software engineer

Wikipedia: Software architect

IBM developerWorks: Characteristics of a software architect

Magpie Brain: A Tech Lead Manifesto

vanderbilt.edu: Project Roles and Responsibilities (Word .doc!)

it’s a delivery thing: Agile Project Roles and Responsibilities

Stack Overflow: Does a software architect have a role in agile, esp. Scrum?

Wikipedia: Scrum Roles

InfoQ: Mapping Traditional Software Development Roles to Scrum

Code Better:Classic Technical Lead Blunder

Atlassian: Tech Leads Talk

Two comparisons of different programming languages worth reading

Normally these kinds of pieces are worthless, but these two recently stood out to me:

Dennis M. Ritchie: Five Little Languages and How They Grew: Talk at HOPL* March 19, 2002

Michael Tsai: Perl vs. Python vs. Ruby – distinguished for the thoughtful replies in the discussion thread.