TDD Is Dead Sale

Posted April 30, 2014 by Joshua Kerievsky in Learning

We recently found out that Test-Driven Development is dead!! David Heinemeier Hansson broke the awful news on his blog. We are heartbroken, to say the least! Over the years we’ve come to rely on TDD for: focus confidence stress reduction speed simplicity safety building deploying refactoring What will replace it now that it is apparently […]
Read more

5 comments


Avoid Rework Through Behavior-Driven Development

Posted April 10, 2014 by Tim Ottinger in Agile eLearning, Learning

Your team is having a frustrating day. The demo led to arguments and accusations. The feature is not going to ship. This isn’t the first time. The analysts have redoubled their efforts, adding more prose, more diagrams, more explanatory text, yet frustrating disconnects remain. Miscommunication during handoff creates waste and rework. Disappointment creates frustration and […]
Read more

1 comment


The History of Microtests

Posted April 9, 2014 by Ingmar van Dijk in Agile eLearning, Extreme Programming, Learning, Test Driven Development

At Industrial Logic we use the term microtest instead of unit test. What is a microtest and why don’t we use the standard industry term, unit test? Watch Mike Hill (aka Geepaw Hill) explain what microtests are, how they differ from unit tests and their connection to Test-Driven Development.
Read more

4 comments


Are you risking your health and creativity by sitting all day?

Posted February 24, 2014 by Industrial Logic in Anzen, Anzeneering, Culture, Health, Learning, Tech Safety

Foggy brain. Poor circulation. Back trouble. Decreased life expectancy. Yikes. This is your fate if you sit at a desk all day. Have you considered standing while you work? Several hundred thinkers at Facebook prefer to stand for the same reasons that da Vinci, Bonaparte, Churchill, Dickens and Hemingway did: They can think better standing […]
Read more

4 comments


Avoid Hazards by Making Decisions Once and Only Once

Posted November 11, 2013 by Curtis Cooley in Learning

Once a decision is made in your code, using flags and decision statements to make the same decision over and over again is hazardous. The safe way is to remove the duplication and make the decision once and only once.
Read more

No comments


Selenium Testing: More Dangerous than We Thought?

Posted October 24, 2013 by Patrick Welsh in Agile eLearning, Extreme Programming, Learning, Tech Safety, Training

Selenium (Se) is a useful but dangerous tool. For example, it is extremely useful for cross-browser, multi-page scenario testing.
Read more

No comments


Fashion-Driven Development

Posted October 14, 2013 by Joshua Kerievsky in Learning, Refactoring, Software Design

In his foreword to the book, The Joy of Clojure, Steve Yegge shared this insight: “The global programming community is fashion-driven to a degree that would embarrass haute couture designers from New York to Paris.”
Read more

14 comments


Stories: Small is the New Big

Posted October 2, 2013 by Patrick Welsh in Agile Transition, Coaching, Learning

We were taught, ages ago, to write User Stories so that they made business sense: As a [role], I want [some ability], so that I can [accomplish something valuable]. These days, we realize that’s not really ideal — at least not for the small things we chunk our work into, and commit to delivering for […]
Read more

1 comment


Tech Safety In DeMarco’s Classic

Posted June 21, 2013 by Joshua Kerievsky in Learning, Tech Safety

Tom DeMarco made software analysis and development inherently safer in 1978 when he published his classic, Structured Analysis and System Specification. Even back then, Tom saw how unsafe it was to: shoot once for perfection write giant specifications define behavior via ambiguous language let software maintenance costs soar produce poorly designed code perform insufficient testing
Read more

No comments


Why Are Most Agile Adoptions Failing?

Posted June 20, 2013 by Amr Elssamadisy in Learning, Tech Safety

Most agile adoptions show very little success.  Most teams show only a moderate increase in productivity.  Based on my experience and many conversations over the years, I’d say that only 10% of agile development teams actually reach “high performance” where they are achieving 200% to 500% improvements.  We can do much better than that.  And a key step is […]
Read more

12 comments