-- Robert C. Martin
Yes, I'm back with Bob. There were some competitors for my attention for this session, but I've decided to play it safe. The fact that I've never heard Uncle Bob talk until this morning's keynote also influenced my decision. I'll maximize my exposure while I can.
The one thing I can count on with Uncle Bob is that I will be entertained. There's something to be said for that.
One question posed right off the bat: Does agile mean the abandonment of architecture? Does it mean no design?
Architecture - we don't know exactly what it is. It is defined differently by many different people. "Design" is a similarly ambiguous term.
"The whole 30 day thing kind of failed. Too much can go wrong in 30 days. My favorite at the moment is 2 weeks and I'm hoping to get to one week very, very soon."
Velocity tracking and estimating are seriously flawed practices. Things "jitter around," according to Uncle Bob. You will not achieve precision with these practices. They are also measures of how fast or efficient teams are getting things done. But they in no way track iterative architectural development.
This type of slice-by-slice development, we only implement "just enough" of the 'grand vision' done (where 'grand vision' means, in general, the entire architectural space of a project). In keeping our heads down in the smaller iteration, we can overlook the overall architecture and how it's shaping up. We may not be evaluating correctly.
The better solution is to think of the small iterations as drafts of a paper. When we're done with the first iteration or 'draft,' we start our second iteration and see what has to be reworked, thrown out, improved. When we complete our second iteration and have a new, improved "draft."
The message so far seems to be "throw away" what's working or fitting with the 'grand vision.' It generally only takes half the time to recreate something that we've already engineered.
It's worth pausing here to note that Uncle Bob just tried to slide in a reference to "An American Tale." That almost blew my mind. I'm still reeling. Ok, onward...
The best thing to do with architectural decisions is to defer them as long as possible. Don't choose your database until the last responsible moment. (Side note: I violated this rule almost immediately in trying to implement Uncle Bob's examples in "Agile Software Development." You can see that in one of my earlier posts. One of the first real-world lessons I learned from the book.)
Uncle Bob's example was his experience with Fitnesse. They knew "all along" that they needed a database. But they deferred and deferred until they realized that they actually never needed a database. They wrote from RAM to flat files over and over, iteration after iteration, until they realized that the database wasn't needed at all. The original Fitnesse, and the version which still exists today, is not db-dependent. To paraphrase Uncle Bob, they pushed off the database requirement, and pushed it off, and pushed it off until it fell off a cliff. What a metaphor!
Design - quick design sessions are useful. Whiteboarding is essential. But the best place to keep all of those resulting design decisions, dependencies, etc... is in the developers' heads. This is the goal, difficult though it may be to achieve.
Lots and LOTS of talk about why to use TDD. I thought that Uncle Bob was past telling people why to use the principles of good design. TDD, CI, pairing - we already know these are good, we are done convincing people, you are being ridiculous if you don't implement these practices. That's what I gleaned from Uncle Bob's keynote. I liked that. I'm tired of explaining why they are effective and I'm tired of having someone explain it to me. If you've been developing for over a year, have heard of all these terms, and you haven't been sold, I'm sorry. I don't want to fight with you anymore. You're probably just not that good and I certainly would regard you with skepticism if I had to work with you. Let's just put it out there. Ok, digression finished.
What I do enjoy from Uncle Bob's speaking is that he seems to still grasp real-world concepts and experiences "from the front lines." People that have been speaking for years on end are susceptible to losing this ability to relate. Uncle Bob has not.
And here we get another push to get QA requirements put into automated acceptance tests and implemented before the feature is developed. We're trying, Bob, we're trying!
Uncle Bob described a client with a QA manager with 80,000 manual tests. He came from his boss who one day told him he had to cut his budget by 50%. Basically, they had to throw away tests to achieve this. "How did they get into this mess?" Uncle Bob asks. They depended on manual testing. They did not instrument their system to allow for automated acceptance tests.
The deeper issue is that this client was using their resources (their workers) in the wrong fashion. People are not very good at following rote instructions. They make odd decisions. They are imperfect. They may take shortcuts. We want people leveraging computers to make automated tests that run the same way every time.
And one more thing, which you can happily throw in my face anytime: "If a system cannot be tested, the design sucks." Noted. I shall do my best.
There is still a place for architects in an agile environment, according to Uncle Bob. However, they must also right code with the team for some portion of the time. They must have the experience the same pain and success that everyday developers experience.
No comments:
Post a Comment