09.30.08
Posted in Journal, News, Software Development at 11:10 pm by Pablosan
I started my CodeNotes project for several reasons, and one of them was more of a hope than an expectation. Knowing that I still have much to learn, I wanted to make some of my coding examples public with the hope that others, either with more experience or simply with a fresh pair of eyes, could provide some feedback.
I haven’t built a feedback mechanism into CodeNotes at this point, and there is no plan to change that in the near future. My contact information is easily obtainable, though, and I have been pleased that people have been providing feedback. To many of you, thank you for your kind words, suggestions and even, at times, criticism.
My most recent feedback was on my first Erlang article. In the original version of the article I had commented that I didn’t like my approach but that it was the only way I knew to code the solution. Thanks to an email conversation with Hans “Uli” Niedermann, I have a new version of the article up which, based on his suggestions, contains a much more elegant solution to adding test run time to the output. Mind, this is still not “right”, in that I have added the code to my test when it should be added to the test framework.
So for now, thanks, Uli, for your excellent suggestions. I hope to reciprocate by making a contribution back to the Erlang community soon. For now, you will all just have to make do with the updated article. Consider it a small down-payment. 
Permalink
09.25.08
Posted in Agile, Journal, Software Development, TDD at 12:59 pm by Pablosan
Upon completing a TDD class last week, one of the students made a comment that I have heard many times now: “TDD requires me to really change my software development and design mindset.” It is great to be reminded of that because I have been doing it long enough now that I’ve forgotten how foreign the discipline felt at first. TDD has become a natural part of the way I solve problems.
I was reminded of this a second time just a couple days ago. It was during a great conversation at a job interview. We spent some time talking about Agile methodologies, and then things turned squarely to the technical as I was asked to design a system at the whiteboard. The problem was fairly straight-forward with a couple interesting twists: an excellent choice for an interview. As I began drawing my UML Static Model, I found it awkward. The first thing I did was to draw a box for the main class, then iteratively played with the design, changing class and interface names along the way and moving fields and methods around as I went. I got part way into the diagram and declared “at this point I would have already been coding, using TDD to help me flesh out the design.” There was a lot of refactoring along the way, even though I was supposed to be doing pure, up-front design.
At the end of the exercise, the interviewer’s comment was telling: “I was expecting a more traditional approach to design, where you would have listed out the nouns in the system and started building classes from there, but I can see how your TDD experience has changed your approach to design yet you ended up at the solution I was expecting.”
So the way I got to the answer wasn’t orthodox and that may impede progress as far as a job offer is concerned. Nonetheless, I went away from the interview beaming. I think I can officially declare I am “test-infected” because, even when I’m not actually coding, I’m still using the TDD mindset. I thoroughly enjoy the fact that this approach to software development encourages me to throw together a minimalist design, and then play with it until it’s right. “Make it work. Make it Right.” Ask me to go back to big up-front design, though, and I won’t get there without some gear-grinding. My mind just doesn’t naturally think that way anymore.
EDIT: I decided to go with the industry cliché, “test-infected.” “TDD-infected” was sounding a bit too… scary.
Permalink
09.16.08
Posted in Agile, Journal, Software Development, TDD at 5:26 pm by Pablosan
One of the reasons I know I am a geek is that I like math (or “maths”, if you’re from across The Big Pond). I’m not as knowledgeable on the subject as I’d like to be, but it does fascinate me. Part of the reason is that I had an incredible Algebra teacher, Mr. Eno (“The Backward onE”), in Junior High School. And part of the reason is that I’m just weird that way, I guess.
I have only ever taken one college course in programming: a C Programming course at Grand Rapids Junior College many, many years ago (1986 or so). One of our assignments required us to compute primes. We were paired up (I was Pair Programming when Pair Programming wasn’t cool), and my pair just so happened to be a math whiz. I learned a lot about Number Theory in the few hours we worked together. I also learned that he was a bit… well, weird (Pot – meet kettle).
I’ve continued to dabble in Number Theory here and there, and so it’s really no surprise that my idea for a fun, Advanced TDD exercise would involve computing primes. The trick was turning this into a Java Concurrency example, and I struggled with that (my first chance to catch a clue). I bounced the idea off a couple colleagues/friends (see my post Advanced TDD), and they seemed to have a lot of questions/concerns (clue #2). I finally settled on the grand scheme of computing prime factors, which would require the ability to compute primes as well as a thread-safe collection in which to store the computed primes.
It was about this time that I started having doubts about my approach. And it was also about the same time, after a very enlightening, yet disheartening talk with Gary, that I decided to take the Open-Space approach for the course that was now less than a week away. Problem solved, right?! Well, almost.
The top voted topic in my Open-Space class was threading. As we discussed how we would approach the topic, I made the mistake of mentioning my little pet project and the class was interested. So we started talking about how to compute prime factors. I already knew that the first piece to build would be the ComputePrimes class which, given an ordinal, would spit out the appropriate prime number. So we test-drove that, as I encouraged the class to simply implement a brute-force approach (Make it work). It was a fun exercise and the class started off well.
We then test drove the collection, which was really quite trivial. Along the way we discussed the threading requirements: one thread would be kicked off to compute primes and multiple threads would be kicked off as needed to compute prime factors, some of which may need to wait until the thread computing primes had computed all primes up to the square root of the number for which we wanted to compute prime factors (meaning, we had a complete set of primes needed to solve the problem). This got a bit confusing and I started getting questions about exactly what the threading problem was (clue #3).
Finally, shortly before the lunch break, I said “okay, now we need to Test-Drive making our PrimesCollection thread-safe”, to which one attendee responded “Why?” Huh? What do you mean why? He then proceeded to set me straight by explaining that we only have one thread that will ever write to the collection and that, once a value is written, it will never change. The problem is inherently thread-safe (face – meet brick wall)!
I sent them away for lunch, promising I would work on salvaging the situation. I decided to use Lasse Koskela‘s threading example from his book Test Driven
, a simple counter class that is then accessed by multiple threads. The example went well, and a disaster was averted… almost.
At the end of the day, we came back to our work on primes (why couldn’t I just let it go?!). I wanted to use an approach I had used before on test-driving a binary search to improve the algorithm’s performance. I ended up running into problems because PrimesCollection was static. I would really like to point out my wonderfully positive trait of tenacity at this point, but I’m afraid I sped right past that into obstinate.
Lessons learned:
- Never, NEVER use an example in class you have not thoroughly explored ahead of time (duh)
- KISS – simple examples keep everyone focused on the important stuff
- Ignoring obvious clues leads to a bruised ego.
And that last lesson… definitely an axiom.
Permalink
09.15.08
Posted in Agile, Journal, Software Development, TDD at 2:46 pm by Pablosan
Back in January, a colleague and I were given the task of developing a new set of courses for a newly adopted, “Corporate Standard” test tool – SOATest. Neither of us had any prior experience with the tool. In fact, neither of us had any prior experience with Service-Oriented Architecture. Yet the mandate was to develop three courses: Introductory, Intermediate and Advanced.
The Introductory course was no problem. We both spent enough time researching SOA and playing with the tool that we came up with a two-day course that taught the basics of SOA, the basics of the SOATest tool and even had exercises that showed how the tool could be used on existing projects in the company.
After co-teaching the pilot course, we talked about the next two hurdles. I made the observation that it was ludicrous for the company to expect two guys with no real-world experience to teach higher level courses. As a trainer, credibility is very important to me and, in this particular problem space, we had none.
I had recently listened to a podcast (I believe it was The Agile Toolkit) where the topic being discussed was Open-Space offerings at conferences and I wondered aloud how that approach might work for our next SOATest course. With a little bit of salesmanship (trust me, it was very little, since I have next to none) we were able to convince management to give this a try. We have held many “Open-Space SOATest” classes since then and they have, for the most part, been very well received and quite productive (the trick is to get critical mass: the more people the better with about 4 as the absolute lower bound).
I decided to take the same approach with my “Advanced TDD” course and that, at least, was a good choice. We spent the first few minutes giving everyone an opportunity to list something they would like to cover, and then voted (using Dot Voting) to determine the order in which we would attack the list.
This approach can work really well, as long as you have a group of people willing to share the responsibilities of working through the problems. I had a great group last week and we looked at:
- A home-grown DAO testing framework
- Unitils, a great Open-Source tool that combines DBUnit and EasyMock to make Test-Driving your Persistence Layer much less painful
- Adding tests to an existing Struts Action
- Brainstorming ways to encourage DBE’s used to a more traditional approach to jump on the Agile bandwagon
There was a fifth topic as well: Java Concurrency. This was the piece that I had been working on in anticipation of providing a more traditional workshop. And it was the one part that… well, had a few snags… which I’ll dig into next time.
Permalink
09.12.08
Posted in Agile, Journal, TDD at 2:51 pm by Pablosan
I discovered an interesting phenomenon while working on my Advanced TDD class: the deeper one delves into a practice, the more specific the application of that knowledge becomes. I don’t know if this is quite a universal axiom, but I’m guessing it’s pretty common.
The idea for an advanced class sprung from one particular slide in the Intro course. A slide that briefly touches on some of the stuff in software development that is hard to test-drive: UI, threading, and database access specifically. I’ve also noticed that the solution to all of these can be generalized into two quite common and highly regarded software development principles:
So my intent was to pick one of the tough things to use as an example for demos and exercises and challenge the attendees to concentrate on the principles, because I knew that, no matter which tough thing I chose, the details would not apply to everyone in the room.
To put it another way, my challenge was to try and genericize something that was inherently specific. By process of elimination I ended up choosing threading. UI was ruled out because the problem space is much too splintered: Swing, SWT, Struts, Spring MVC, JSF, etc. Simply choosing either a Web-based UI or an application UI fractures the field to begin with. Database access was ruled out for similar reasons: JDBC, Hibernate, Ibatis, Cayenne, Jaxor, etc.
So I chose Java concurrency, which seemed the least fractured and could be taught 100% from the Java Core Libraries. And that is why Jeff correctly thought “Advanced TDD” was a misnomer. There is no way a one-day class could cover a topic as broad as “Advanced TDD” so the title is misleading. His suggestion, “TDD & Java Concurrency” would have been a much better choice. Similarly, any of “TDD & JDBC”, “TDD & Hibernate”, “TDD & Spring MVC” (I see a theme emerging) could make great “advanced” classes. In reality, they would all be teaching the same core principles: only the specifics would change to protect the… er… anyway…
Focusing on the core principles is a good thing. However, since the principles are rather abstract, they need to be grounded in concrete examples. So the right approach would be to come up with a one-day workshop that uses something specific to teach the underlying principles, choosing a title that clearly conveys that to prospective attenders. Of course, that also means that I need to develop several different versions of the same class. It’s a good thing I love learning new things!
There is another approach; one that is a little less prescriptive. But I’ll save that for another time.
Permalink
09.11.08
Posted in Agile, Journal, TDD at 11:56 am by Pablosan
I have had some great successes over the last year, teaching Agile practices and TDD to dozens of teams throughout the Americas. Recently, though, I started feeling the need to revamp the TDD course.
The curriculum I’m teaching was originally a four-day class, and by the time I took it over it had already been shortened to a three-day class without removing any content. Even as a three day class, I was getting consistent feedback that it was difficult for people to take that much time away from their daily responsibilities. So I shortened it to a two-day class: again, without removing content. I would simply cover as much as I could, custom-tailoring each class in an effort to make the most efficient use of those two days.
Continuing with my iterative approach, my latest improvement was to divide the material into several courses. This allowed me to address another concern. Since we were trying to cover a breadth of topics, it seemed to me that attendees didn’t have enough practice with the basic TDD cycle to feel confident enough to use it in their daily coding.
So the two-day course is now a little bit of lecture, a few coding demonstrations, and as many exercises as we can possibly fit in. I’ve only taught this new class a few times, but I can already tell that people are leaving the class with more confidence in their understanding of the basic TDD cycle. Chalk one up in the “Win” column.
The second class is a one-day, TDD & Refactoring class, which I taught for the first time earlier this week. Like the Intro course, this course went incredibly well, giving us a chance to focus on refactoring tests in the morning, and then on refactoring production code in the afternoon. Chalk another on up in the “Win” column.
The third course shares it’s title with the title of this post. I spent a lot of time bouncing ideas off of Jeff, and he felt that the class was mis-named. Another friend and colleague, Gary, had concerns about the exercises – that the real focus I intended for the class would be overshadowed by the problem-space I was playing in. Look for more on both of those in future posts.
Yesterday was the first day I taught the Advanced TDD course. It went pretty well, but I definitely had a few snags along the way. I’m not sure I’d call it a “Loss”, but it definitely doesn’t belong in the “Win” column… yet.
For one thing, the class is mis-named… and the problem space I chose to play in detracted from the salient points I wanted to reinforce throughout the day. But that’s okay. Since I’m taking an iterative approach, it will be much better next time!
Permalink
09.03.08
Posted in Apple, Go, Journal, News, Software Development at 11:28 am by Pablosan
It’s been over a week since I submitted my iPhone Developer Program application, and I still don’t even have official word that Apple has received it. I’m doing my best to be proactive, but I haven’t found a lot that I can do to get answers. I’ve sent off a message via Apple’s “Contact Us” link, but I have very little confidence that anything will come of it.
I know that they aren’t hurting for applicants and I know I’m a very small fish in a very large ocean, but I have always chafed at external and unnecessary delays. I’m quite proud of the work I’ve accomplished and would like the chance to show it off to the world and see how I fare, even if it is a piddly little app.
I know I’m not the only one in this situation, but it is freakishly quiet out there… maybe I should take that as a sign, but for now, I intend to provide occasional updates on this issue here until it has been resolved.
In the meantime, I’ve got some ideas percolating on the game of Go and a new Erlang article or two to publish. Just be prepared for news bulletin interruptions to this blog as notable things occur on the iPhone Developer Program front.
Permalink
