DEV Community: Eljay-Adobe

The TDD Test

Eljay-Adobe — Thu, 04 Oct 2018 15:27:23 +0000

The TDD Test

I have had some experience with co-workers who were doing TDD incorrectly.

The benefits of TDD is that it puts pressure on the developer to use employ several of the SOLID principles, to design for testability, high cohesion, low coupling, and the immediate elimination of technical debt by refactoring before checking in.

In order to underscore the TDD value proposition, I have found that adding one simple little step to the TDD process helps educate developers on how to do TDD correctly.

If the developer is doing TDD correctly, then the additional step won't devalue the process.

I call this The TDD Test. It tests the TDD process.

add a test
run the test - it should fail
write the code
run the test - it should pass
refactor the code - eliminate newly incurred technical debt
run the test - it should pass
check-in
delete the test
check-in

Sure, this loses the residual value of the test. But keep in mind that 99% of the value proposition of TDD is how it guides design-in-the-small.

(The residual value of the test can be recovered from source control. Which is why step 7 is before step 8.)

The TDD Test does not have to done in perpetuity. Just until everyone understands how TDD works.

James Coplien

At the extreme end of the unit testing spectrum is James Coplien. In his “Why Most Unit Testing is Waste” essay, he advocates keeping tests for up to a year, and then getting rid of them.

I do not share Coplien’s opinion, however he makes an interesting case. Depending on your software, what he advocates may be applicable to your situation. I do not believe his advice is applicable in the kinds of software I create.

Coplien is using waste in the sense of Lean’s Muda. He is not using it in the sense of “testing is a waste of time”.

I mention Coplien’s article because The TDD Test was inspired by his paper. The TDD Test just changes his “...up to a year...” part into “...up to a minute...”.

Book Recommendations

Eljay-Adobe — Mon, 06 Nov 2017 13:16:39 +0000

Here are some books that I highly recommend.

For C++, there is the curated list on StackOverflow: The Definitive C++ Book Guide and List. Nothing I could add to that list, or take away.

For JavaScript (ES6), I've been out of the loop too long. I suspect books like Eloquent JavaScript and JavaScript: The Good Parts are out of date, but I found them to be a great help back in the day.

For F#, I've read about a dozen books on the topic. Only one book have I found to be useful so far:

The Book of F#, by Dave Fancher, a fantastically fabulous book
disclaimer: I haven't read "Expert F# 4.0" yet, which I hope and expect will be good, even if the reviews call it "preachy"

For agile, I've really enjoyed these books:

The Scrum Guide, by Schwaber and Sutherland, is nice, very short, definitive, and free (PDF)
Succeeding With Agile, by Mike Cohn, is a "must have" book for agile
How To Implement Scrum in 10 Easy Steps, by Kelly Waters, is an online article, but I'd be remiss if I didn't call it out here. Scrum really is that simple... in theory.

For general development, I have these heavily dog-eared books on my top shelf:

Writing Solid Code, by Steve Maguire
Code Complete, by Steve McConnell
Clean Code, by Robert C. Martin
Design Patterns, by Gamma, Helm, Johnson, and Vlissides
AntiPatterns, by Brown, Malveau, McCormick, and Mowbray

On my short queue of books to read that have been highly recommended to me:

Refactoring, by Martin Fowler, et al
The Pragmatic Programmer, by Hunt and Thomas
Growing Object-Oriented Software, Guided by Tests, by Freeman and Pryce

What are some book recommendations you would like to share?

Scrum is Easy

Eljay-Adobe — Tue, 12 Sep 2017 14:51:26 +0000

Scrum

Lightweight Management Process

Scrum is a lightweight management process. It was adapted for software development from "The New New Product Development Game", which described The Toyota Production System.

Scrum is typically associated with software development, but some companies have taken it further and claim that Scrum works everywhere.

The reason that Scrum can work beyond software development is because Scrum is a lightweight management process. Scrum itself does not embody agile values, principles, and technical engineering practices.

That needs to be emphasized: Scrum is not agile. Scrum is lightweight.

Because Scrum is a lightweight management process, it can be very complimentary to agile software development.

The Scrum Guide (it's free!) by Schwaber and Sutherland fulfills the management aspects for a project, but delegates the agile engineering practices to the development team.

Scrum as a lightweight management process consists of roles, events, and artifacts.

Roles are: scrum master, product owner, and the development team.

Events are: planning product backlog, dev team planning sprint backlog, daily scrum stand-up, sprint review, sprint retrospective.

Artifacts are: product backlog, sprint backlog, increment of the business value added to the product at the end of the sprint, and sprint burn-down chart.

Not Scrum

Sometimes Scrum goes awry. Where do things go awry?

Scrum becomes "not Scrum" when the Scrum process isn't followed. SHOCKING!

In my experience, these are the critical parts that are not followed, which makes Scrum not work:

fancy, expensive Scrum tools - Kelly Waters (see link below) explains why you want basic and effective tools for Scrum, rather than frilly Scrum software that is efficient but harmful to individuals and interactions
no full-time scrum master - without a scrum master to manage the process, the process will be adrift
scrum master is not considered a management position - scrum master does not manage people, the scrum master manages process ... and that is a management position
lack of training for the product owner, the scrum master, and/or the development team - the new process may be simple, but it ain't easy; sure-est way to kill Scrum is to tell everyone "do Scrum" but not train them
no single individual as the designated product owner - too many bosses making product decisions results in paralysis
development team is not empowered to make technical decisions - if the development team cannot decide which version control system to use, which programming language to use, which agile engineering practices for the team to embrace, where the curly braces go, tabs or spaces, yada yada yada
facilities are not set up such that they facilitate team dynamic - the development team needs to be focused on the project, and facilities is the EASIEST thing to set up when adopting Scrum, yet some companies neglect this simple but vital step for the team to have a war room, to have cubes or offices that have a shared common space. (Teams that are not co-located will face additional challenges, but not impossible.)
corporate antibodies undermine Scrum as a management process - here's where the scrum master and management support can grapple with other departments who are disrupted by the change in management process to Scrum. And without a full-time scrum master to wrestle with these issues, the corporate antibodies will force the project to fallback to previous management process practices.
development team gravity, organ rejection, backsliding into the comfort zone of old ways
project management office (PMO) at odds with Scrum as a lightweight management process - the scrum master, once again, should act as a liaison with PMO. But if there is no full-time scrum master, or if the scrum master is not yet experienced and is learning the ropes, making an adversary of PMO is bad, and PMO should be an ally.
lack of corporate commitment - if the company is not committed to supporting, embracing, and transitioning to Scrum, then it is doomed; corporate antibodies will flay it alive
Scrum is flexible! - some people hear the message that Scrum is flexible, and you can do whatever you want. So what they do is torpedo the Scrum management process from the onset. The flexibility in Scrum does not give license to not do Scrum under the pretext of doing Scrum. The flexibility is in it being a lightweight management process, and that the development team is empowered to make technical decisions and employ agile engineering practices.

Who is PMO, anyway?

For larger corporations, PMO acts as the monitor for all projects in the company on behalf of the executives.

For a smaller company, that responsibility may be on the shoulders of a single executive. The CEO, the president, or a VP.

Their ultimate responsibility is to decide which projects are funded, how well those projects are doing (green light, yellow light, red light), if a project is in trouble, and if a project should have additional staff, destaffed, or cancelled.

They inform the executives, who then make the hard decisions.

So having PMO on board with a project is critical for the success of the project, regardless if Scrum or some other management process is being used.

Where to start?

Read The Scrum Guide by Schwaber and Sutherland, the creators of Scrum. It's short: 16 pages. It's free.

Read How To Implement Scrum in 10 Easy Steps by Kelly Waters. It's goes step by step on how to get started with Scrum.

References

The Scrum Guide by Schwaber and Sutherland, the creators of Scrum
How To Implement Scrum in 10 Easy Steps by Kelly Waters
Succeeding with Agile excellent book by Mike Cohn
Fad Agile by Eljay (me!)

Hi, I'm Eljay-Adobe

Eljay-Adobe — Thu, 13 Apr 2017 16:32:25 +0000

I have been coding for 39 years.

You can find me on GitHub as Eljay-Adobe

I live in Minnesota.

I work for Adobe Systems Incorporated.

I mostly program in this language: C++. But have programmed in many, many others. I like Python and Lua. I use Vim.

I am currently learning more about Modern C++ (C++11, 14, 17), Swift, and F#.

Nice to meet you.