Balancing automated and non-automated testing

Actually the following talk is on automated, manual, early cycle, and late cycle testing, and test planning, crowd sourcing, and dog-food programs, and more.

YouTube: GoogleTechTalks: “Turning Quality on its Head” Presented by James Whittaker, Engineering Director, Google Inc.

Google docs: slides

Joshua Bloch on “How To Design A Good API and Why it Matters”

This is a great Google Tech Talk and while it may be Java-centric, I think much applies to any language you work with.

YouTube: GoogleTechTalks: “How To Design A Good API and Why it Matters”:

This is what I believe is the PDF slideshow from the above presentation.

There is a version of this presentation at InfoQ if you prefer that over YouTube and PDF.

InfoQ: Joshua Bloch: “Bumper-Sticker API Design”

Artima: Joshua Bloch: “Josh Bloch on Design”

Recent programming career recent reads

Tony Lukasavage: “Programmers: Why do we do it?”:

…those who truly love programming see it as an art form. Its not just a technical pursuit, but one that allows the leveraging of one’s unique talent and views. You bring a form of personal expression into your work. You invest yourself physically and mentally in what you do. You suffer and toil, using code as your medium, just as other artists craft with paint or stone. You have a personal association and pride with its creation. The code and its results represent you.

Chad Fowler: “Dead-End Jobs: Are You Suffering From Stockholm Syndrome?” (reddit conversation):

According to the Bureau of Labor statistics, American adults spend by far more time working than any other activity. That’s a lot of your waking time being trapped in a routine. In a Stockholm Syndrome situation, the captor chips away at the self-esteem of the captive. So for most of our waking hours, those of us trapped in dead end jobs like these are exposed to environments which systematically destroy our self-confidence. Not only that, a persistent fear and feeling of failure makes it harder to actually explore the options for leaving the bad situation. The instinctive self-preservation reaction in this kind of situation is to work harder to try to avoid the perceived threat coming to fruition.

David Veksler: “Some lesser-known truths about programming” (lots here, but I want to quote the following in particular since when I use the words ‘conceptual integrity’ I get blank stares too often!):

Software obeys the laws of entropy, like everything else. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are killed.

Martin Fowler: “Is Design Dead?”:

…I think there is a role for a broad starting point architecture. Such things as stating early on how to layer the application, how you’ll interact with the database (if you need one), what approach to use to handle the web server.

Essentially I think many of these areas are patterns that we’ve learned over the years. As your knowledge of patterns grows, you should have a reasonable first take at how to use them. However the key difference is that these early architectural decisions aren’t expected to be set in stone, or rather the team knows that they may err in their early decisions, and should have the courage to fix them. Others have told the story of one project that, close to deployment, decided it didn’t need EJB anymore and removed it from their system. It was a sizeable refactoring, it was done late, but the enabling practices made it not just possible, but worthwhile.

How would this have worked the other way round. If you decided not to use EJB, would it be harder to add it later? Should you thus never start with EJB until you have tried things without and found it lacking? That’s a question that involves many factors. Certainly working without a complex component increases simplicity and makes things go faster. However sometimes it’s easier to rip out something like that than it is to put it in.

So my advice is to begin by assessing what the likely architecture is. If you see a large amount of data with multiple users, go ahead and use a database from day 1. If you see complex business logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the side of simplicity. Also be ready to simplify your architecture as soon as you see that part of the architecture isn’t adding anything.

…In order to work, evolutionary design needs a force that drives it to converge. This force can only come from people – somebody on the team has to have the determination to ensure that the design quality stays high.

This will does not have to come from everyone (although it’s nice if it does), usually just one or two people on the team take on the responsibility of keeping the design whole. This is one of the tasks that usually falls under the term ‘architect’.

This responsibility means keeping a constant eye on the code base, looking to see if any areas of it are getting messy, and then taking rapid action to correct the problem before it gets out of control. The keeper of the design doesn’t have to be the one who fixes it – but they do have to ensure that it gets fixed by somebody.

A lack of will to design seems to be a major reason why evolutionary design can fail. Even if people are familiar with the things I’ve talked about in this article, without that will design won’t take place.

…So is Design Dead? Not by any means, but the nature of design has changed.

Joel Spolsky: “The Guerrilla Guide to Interviewing (version 3.0)”

Joel Spolsky: “The Joel Test: 12 Steps to Better Code”

Joshua Thijssen: “The software managers “joel test””

Lucas Ward: “Maven and Continuous Delivery”

Uncle Bob: “Incremental Architecture”

Steve Yegge: Good Agile, Bad Agile

InfoQ Presentation: Martin Fowler and Rebecca Parsons: “Agilists and Architects: Allies not Adversaries Presentation”

Martin Fowler: Domain Specific Language

InfoQ Presentation: Martin Fowler: “Introduction to Domain Specific Languages”

Dave Thomas: “The ‘Language’ in Domain-Specific Language Doesn’t Mean English (or French, or Japanese, or …)” “The Nature of Lisp”

Jun Auza: “Top 50 Programming Quotes of All Time”

Antipatter: “How to Manage A Tech Career”

Great Michael Feathers presentation on testing and design

The Deep Synergy Between Testability and Good Design from Tim Yann on Vimeo.

Google’s Innovation Factory

Fellow Comcaster Jon Moore has been sharing this great paper by Google. Lots to chew on from a very quick read.

2 pieces with lessons on programming

Carl Miller: “The Two Things about Computer Programming” and related reddit thread.

Jonathan Danylko: “20/20: Top 20 Programming Lessons I’ve Learned in 20 Years”

Programming practice links for October 18, 2010

mockyblog: “Programmers: how to make the systems guy love you” – common sense advice that you’d be surprised how many don’t follow.

InfoQ: Abel-Avram: “10 Suggestions for the Architect of an Agile Team” – if you are practicing an agile-lite process, are a senior developer on a team, and have helped usher systems to launch, you will have probably practiced these 10 pieces of advice. I’m not sure if these are applicable practices for architects and am not sure they are applicable for a team that is practicing pure agile.

Artima: Bill Venners: “Tracer Bullets and Prototypes: A Conversation with Andy Hunt and Dave Thomas, Part VIII” – a long rumination on the ‘Start with a vertical slice’ tip from the previous link.

On Visualizing Iterative Waterfall

Go read Jon Moore’s latest piece “The Power of Visualizing Iterative Waterfall”: “the most powerful reason to start visualizing the flow is that it shows you exactly what parts of your process you should change, and when. There’s nothing like being able to show a product manager that their availability is driving overall throughput to encourage spending more time with the team.”

On Being a Puppetmaster

YouTube: “Jim Henson on Making Muppets 1969”:

Four Links on Ideas (and Perspective)

My friend Arpit Mathur posted a great piece today on ideas and implementation: “On ideas, implementation and iteration”. I can relate to this – including the self admonition to hunker down and execute.

The following three links try to make an additional point on what an idea needs – partners. People who have different perspectives from which ideas can clash, evolve, and grow. There is an opportunity in sought out diversity of background and opinion to make something that much stronger.

Or to put it another way, if your project has its Lennon, does it also have its McCartney?

YouTube: “Steven Johnson: Where Good Ideas Come From” (via Boing Boing):

Slate: Joshua Wolf Shenk: Two Is the Magic Number: A new science of creativity.: “a new body of research has begun to show how growth and achievement emerge from relationships”.

And while this last link is not centered on ideas and creativity, it applies directly if you take the above to heart I think:

The Most Powerful Word In The Human Vocabulary: Perspective:

Choosing a career path is tough, and the education system doesn’t make it much easier. They try to guide you towards one of these worlds that exists on our planet. The problem is that most of the time, schools don’t understand the unique perspective of their students, and they don’t adapt their needs to the situation. This is why finding your passion is so important. Passion is not the be-all-end-all, but rather the guiding force that allows us to make the right decisions as we travel through life. Finding your passion, connecting with your tribe and achieving your goals are the steps that you must take in order to find a career that you will find rewarding. But having a sense of perspective for the world around you allows you to understand that your opportunities are endless.

Never let someone with little perspective guide you away from your passion. Next time you have a conversation with someone who doesn’t understand why you are doing what you are doing, try to understand their perspective. How were they raised? What was their path in life? This will often let you understand why they are making the statements they are. By getting this, you can understand where they are coming from. People that are not in your world will very often not have the same perspective to you. Remember, that’s what makes the world so unique and wonderful.

This post is pretty much me talking to myself as I have a few coals in the fire and some additional perspective will go a long way, but I think the links are inspiring and hope you enjoy.

Update: Arpit shares a link that in some ways reinforces the idea above: WSJ: “The Origins of Good Ideas”“the adjacent possible.”.