Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Overview

Many people who explain agile software development often discuss project and planning practices, but hardly mention the development phase. In this insightful video, renowned software architect Neal Ford drills into the real details of agile engineering practices from a pure development perspective. Discover the development and design practices that make the agile approach work, the pros and cons of feedback mechanisms, and a host of related topics.

Subscriber Reviews

Average Rating: 3.823529411764706 out of 5 rating Based on 51 Ratings

"no real thought leadership, just consultant speak." - by Ada Lovelace on 13-FEB-2014
Reviewer Rating: 1 star rating2 star rating3 star rating4 star rating5 star rating
Test-driven Design Part 1:
- constructs a straw man class to justify the use of TDD.
The class he uses is the Classifier class. For the "test after" code he intentionally makes it bad. For example it's obvious that a set would have solved the 'edge case' problem and it's also obvious that it should have been broken up into separate methods. Doing that pretty much makes it look the same as the TDD class.
The way the Classifier class is constructed is wrong, he populates it with a couple of factors in the constructor then the calculateFactors method calculates the rest of the factors- this is really really bad from a semantic point of view. It leaves the Classifier object in an invalid state after calling the constructor.
Also I have no idea where the notion of "if it's more than 10 lines then it must be wrong" comes from, I call BS on it. Hi opinion is not based on any emperical evidence. The emperical evidence I've seen is that methods can be a screen length in size - it's a good chunking size for your brain.

Test Drive Design Part 2:
Gives an example of a Thoughtworks project in the UK, simple web site - uses 45,000 lines of code with 7905 methods, which is an average of 5 lines of code per method. They do that as they're fixated on cyclomatic complexity, apparently on this project it was 0.26. Good luck for the client maintaining code which has 5 lines per method. Can you imagine how many methods you have to go thru to see how even the most simplest functionality works! Sure you cyclomatic complexity is low but you've insanely increased your "comprehension complexity" (my consultant buzzword, maybe I'll write an article about it)- imagine if you wanted to modify that codebase. I can't believe this guy says it like it's a good thing!

Pair Programming:
Pair programming is done on pairing computers in which there are only dev tools. and nothing else like email etc... It's more efficient than people doing normal development on their normal computers - Hey it's more efficient because they can't do anything else on the pairing computer but write code! Duh. Talks about left brain and right brain based on Andy Hunt's "Pragmatic Thinking and Learning: Refactor Your Wetware" and that we can only either be left brain thinking or right brain thinking at one time that's why according to his opinion (he trys to state it as fact) pairs programming is sooo good because one person is using left brain, one person is using right brain. Well surprise, surprise now we know that this isn't the case. According to recent scientific studies there is no left brain/right brain separation - we always use our whole brain. So kind of puts a damper on that line of reasoning.  Talks about flow and how pairs programming is good for flow - well a better booster of flow would be an office with a door. Tom Demarco in Peopleware pretty much said this, similarly Microsoft gives developers private offices as well.

Automation:
- automate testing using selenium - wow that was an earth shattering suggestion
- talks about continuous delivery and deployment and gives example of flickr and itsy - come on that's not impressive, they're non mission critical businesses.  Continuous delivery works well for non mission critical systems i.e. most web 2.0 startups and social media companies fall into this category. .
- automate as much of your "day to day" tasks as possible with scri[pts/programs etc... This was suggested 14 years ago in "The Pragmatic Programmer" by Dave Thomas - great book by the way, much much better than the presenter's book "The Productive Programmer". Dave Thomas is on another level - he's considered by many as one of the original "thought leaders" in developer productivity, not just a consultant trying to project "thought leadership".

Version Control Strategies:
Everything in there is obvious to a developer with more than 1+ years of experience. Nice buzz word "Feature Toggle", in my days they were called configuration switches. i.e. something in your code you turn on and off to test features which may/may not be complete. I like the way consultants come up with new terms for existing terms.

Agile Design:
Lots of buzzwords - evolutionary architecture, emergent design.
Takes a shot at waterfall because a lot of the projects fail, I think your milage may vary with this as most of the projects I've worked on in pre-agile days actually were successful. Neal goes on about guys writing software for the space shuttle etc... Well I know for a fact that when launching space shuttles or satellites there's no emergent design or even agile in the process. There's tons of design, tons of design reviews etc... It definitely ain't TDD or really agile. No matter how much you pretend it is.  Another made up term "idiomatic patterns" - we call these best practices or design guidelines, but calling it "idomatic patterns" means you can write books and articles about it - it sounds so much more sexier.
Also he makes quite a few comments about enterprise architecture, but unfortunately his background isn't working in large corporations or in designing enterprise wide systems which need to touch on a multitude of services. His background seems to be fairly straight forward web applications; so security, dealing with regulatory forces, having a common architecture which can be reused across projects etc... he doesn't seem to have much experience of, hence his view that we don't need much upfront design; which is valid again when you're developing faily simple systems. He gives an example of a media website developed by thoughtworks (the one with 5 line methods) as an example. I think this example speaks volumes about the context from where he's operating from.

Report as Inappropriate

"good topic coverage" - by Praveen Gunasekara on 25-DEC-2013
Reviewer Rating: 1 star rating2 star rating3 star rating4 star rating5 star rating
good coverage on all topics at a high level.
will be very useful for someone who have a java background.

Report as Inappropriate

"Very Informative" - by hdjourney on 04-DEC-2013
Reviewer Rating: 1 star rating2 star rating3 star rating4 star rating5 star rating
It was great to watch Neal and explain some of the concept not only from the engineering standpoint but also how it applies to different programming languages. Great perspective on real world agile practices and more.
Report as Inappropriate

"Very good explanation of agile methodology" - by jitesh biswal on 25-DEC-2013
Reviewer Rating: 1 star rating2 star rating3 star rating4 star rating5 star rating
I have learned a lot after completely viewing this series of videos. I 'll recommend everyone to see this
Report as Inappropriate

"consultant level story about software engineering" - by Anonymous on 10-APR-2013
Reviewer Rating: 1 star rating2 star rating3 star rating4 star rating5 star rating
not at commercial software level / short class software companies...
Report as Inappropriate

Table of Contents

Chapter/Selection

Time

Key Principles

Preview

00:41:08

Estimation

Play Video

00:57:03

Test-driven Design Part 1

Preview

00:41:07

Test-driven Design Part 2

Preview

00:27:02

Pair Programming

Preview

00:49:48

Automation

Preview

00:46:21

Version Control Strategies

Preview

00:23:54

Testing the Entire Stack

Preview

00:32:13

Functional Tests

Preview

00:34:49

Agile Design

Preview

00:39:49

Emergent Design Enablers

Preview

00:32:47

Extras

The publisher has provided additional content related to this title.


Description
Content

Visit the errata page for Neal Ford on Agile Engineering Practices

  • Errata

Download the supplemental electronic content for Neal Ford on Agile Engineering Practices

  • Supplemental Content

Visit the catalog page for Neal Ford on Agile Engineering Practices

  • Catalog Page