Hanging out with industry leaders...
Thanks to Near Infinity's generous training budget, I had the opportunity last week to spend 3 days with several members of the Object Mentors group. These guys have an enormous amount of experience, especially "Uncle" Bob Martin. So I thought I would share a few of the pearls of wisdom they dropped along the way:
- "Programming is a social exercise" - I thought this was a really good point. It was mentioned in the context of pair-programming, but I think it has far-reaching implications. Software development is more than just running through a bunch of formulas and crunching out an answer. Interaction within the team and with domain experts is crucial, to not only build the software right, but build the right software.
- "A refactoring is something that takes a few seconds, or a few minutes at most" - I was really impressed with the importance of automated refactorings in his discussions. I think most of the time that I spend "refactoring" is in small, manual edits, whereas most of the time that he spends is in using automated refactoring to "chunk" his edits. I definitely need to learn these keystrokes and refactorings better. Maybe I should start a "Refactoring Driven Development" movement...
- "Don't put refactoring on the schedule; do it all the time" - Simple, but effective. My tendency is to want to spend all my time refactoring, but this curbs that, because it forces me to refactor while I'm delivering user stories.
- "There are 3 essential design skills: nose, vision, and plan" - A nose for recognizing design smells, a vision for seeing a good design for your codebase, and an ability to come up with a plan to get from point A to point B.
- "Testing trumps good design" - This bothered me at first, but I think it's a really good point. The idea here is not to say that design is not important. But, rather, if you are forced to choose between between a "bad" design that allows better test coverage (e.g., less encapsulation), and "good" design which is hard to test, choose testability. The reason here is that the biggest roadblock to changing your codebase is not bad design, but FEAR of breaking something. If you know you will know when you've broken something, then you can retrofit a better design later.
- "There is self-worth tied up in "finishing" something" - He also drew a distinction between having something working (which some developers will call "finishing" it), and finishing it - making it not only work, but be thoroughly tested, maintainable, etc.
- Presentation layer - he talked about having the thinnest possible UI layer, which talks to a presentation layer to find out everything about how it should render. Then test the UI and business logic completely separately
- "You aren't doing agile development unless you are tracking your velocity and remaining story points in terms of passing, automated acceptance tests" - I balked at this at first, feeling like it was too easy to use this as a performance to beat the team over the head with. After I thought about it, though, it's really about the definition of done. We are done if all the features we said would be working are working. And how can we know this? Only by testing them. Continuously. Which means it should be automated.
- Acceptance tests don't need to be end-to-end, and, in fact, shouldn't be. This is another one that made me hesitate. After all, how do you know the feature is really working unless you go all the way from the UI to the database and back? Well, in short, because you're the developer. There's more value in being able to test features fast, constantly, than in being able to truly test them all the way from one end to the other. Mock/stub out what you need to to make that happen.
- FitNesse is cool. This is the second time I've played around with that tool, and the second time I've been impressed with its power and simplicity. I definitely need to play around with it some more.
2 Comments
Leave a comment
0 TrackBacks
Listed below are links to blogs that reference this entry: Hanging out with industry leaders....
TrackBack URL for this entry: http://www.nearinfinity.com/mt/mt-tb.cgi/1566
--Acceptance tests don't need to be end-to-end, and, in fact, shouldn't be.
I totally agree with this, but would add that end to end tests are STILL needed! Many defects are only found after components are integrated and features are used together. A good balance of automated checks and thoughtful human run tests can be used when appropriate for extra test coverage. I realize talk of any tests run by people is unpopular right now. It would be nice if they were unpopular because they weren't finding bugs anymore since we've eliminated introducing bugs and are catching them early rather then being unpopular because they are expensive compared to more automated checks.
These are some great points. As a tester, it is inspiring to see so much thought go into the craftsmanship of the code as well as the testability.
"Acceptance tests don't need to be end-to-end, and, in fact, shouldn't be" --> I think it is contextual. On what basis would you say acceptance shouldn't be end to end. From an end user perspective, does this application help him put the data and see the same data being retrieved later time or is it lost.
If it is multi-integrated system where data flows from one system to another and to another and then circles back to the main stream again, it is absolutely necessary to have the end2end for data validity and not lost or corrupted anything between the systems. you wouldn't want to find such issue when deployed in production with real customer data, correct?
just my thoughts on this point. I like the observation around refactoring. I agree it should be all time and not necessarily one scheduled time..
thank you for your summary...