08.29.10
Posted in Agile, BDD, Iterative Development, Pair Programming, Software Development, TDD, Teams, Uncategorized at 7:41 pm by Pablosan
Recently I was honored to have the opportunity to work toward being approved to teach Ron Jeffries’ and Chet Hendrickson’s Agile Developer Skills course. I had my first opportunity to co-teach the class last week. It was a great class and I very much enjoyed working along side Chet and Cheezy, two software craftsmen I respect highly.
If you follow the links above, you’ll notice a theme and, though it’s not explicit in the class’ title, Extreme Programming is a significant influencing factor in the course content. Like most software developers, XP has had a major positive impact on my pursuit of the craft, and it’s great to see the practices hold up so well over time.
The ADS course utilizes some lecture, but it is primarily a hands-on workshop giving participants the opportunity to experience developing high-quality, working software using Agile principles and practices. This is the second time I have experienced the class (the first time was as a participant back in May) and it has remained an intense, thoroughly enjoyable way to either learn the practices for the first time or to delve deeper into Agile. I find it hard to believe that anyone could leave the course without learning a great deal. It is both challenging and insightful.
I think my favorite part of the class are the questions and how they help shape and guide the content. That feedback is crucial to the success of the course (maybe any course) and, as an instructor, I find the questions leave me thinking about these principles long after the class is over.
Next time, I’ll share a couple of the questions and some of those thoughts. For now, though, I encourage you to take a look at Agile Skills Network and consider taking the course. Regardless of where you are in your software craftsman journey, the ADS course will encourage you to push further down the path!
Permalink
02.18.10
Posted in Agile, Iterative Development, Software Development at 6:57 pm by Pablosan
In my previous post I went out on a limb and claimed that, while Agile places a high level of importance on “Business Value”, too many Agile projects seem to miss the mark when it comes to providing real value in the real world. To be fair, Agile methodologies have primarily focused on delivering working software in an iterative fashion, which is only a small portion of the overall process of seeing a gleam in one’s eye become a tangible, usable product.
Fortunately Agile is about executing, learning and adapting and I am beginning to see a push in two directions: both into the activities that lead up to the project’s visioning exercise and into assessing the value the project is providing in the real world.
One of the things that I really appreciate about Agile is the vetting process that helps a team prioritize the work in the backlog based on Business Value. This insures that those features having the highest potential for the most business value are completed first. This is highly effective in the confines of a given project. However, nothing in this process addresses: 1. how this project fits into the overall vision of the organization, 2. how the value of this project compares to other projects in the organization, and 3. A sense of whether or not the actual user will find the product useful.
In all fairness, it can be argued that these concerns fall outside the responsibilities of the project. But I submit that if an Agile team successfully delivers a feature set that does not fit in the overall vision of the organization, or is of less value than other projects that were passed over in favor of this project, or fail to prove useful to the end user, the project is a failure, ergo Agile has failed.
That may seem harsh, but I believe it is accurate. In order for Agile to continue to thrive, it must push forward into the process (or lack thereof) that precedes kicking off the project. Fortunately this is a fairly simple concept. An organization can apply the same vetting process used within the project to the process of selecting which projects actually get worked on and in which order. It is not hard to envision creating a prioritized queue of products or feature sets at a level above the actual project execution.
It is not enough to successfully deliver a project if the project itself is improperly positioned. Agile needs to push upstream. We need to start asking the tough questions:
- How does a given project support the overall vision of the organization?
- Where does a given project fall in the overall prioritization for all work on deck?
- What research have we done to provide a reasonable level of confidence that a given project will provide real value in the real world?
If you are OCD… er, detail-oriented like me, you may have noticed that I have only addressed two of the three concerns I listed earlier. I’ll save the third one for next time. In the meantime, how do you envision your company pushing the Agile values upstream in an effort to provide the right thing to the right people at the right time?
Permalink
Posted in Agile, Iterative Development, Software Development at 5:48 pm by Pablosan
I’m feeling the need to state up front that:
- I am not trying to incite a religious war over the merits of Agile or any given Agile methodology
- I think Agile has been a significant positive force in the IT Industry, driving a focus on continual improvement, quality, incremental delivery and, overall, bringing back a fair amount of science to computer science.
Let me state my assumptions: first, Agile is IT process-centric because it was created by software engineers. The reason the term was coined and the movement birthed is because we in IT were tired of a heavy-weight process that had a track record of setting us up for failure. I am extremely grateful that a group self-organized back in late 2001 to stop the insanity and blaze a trail in a new direction. As is often the case, that which gives us our strength is also our downfall.
My second assumption is that the direction of a project and the details of a process should be driven by providing real value in the real world. I’m sure that some of you are already jumping ahead of me and planning my lynching, because I obviously have missed the point that Agile is all about “Business Value.” Hopefully you’ll give me time to explain. While business value is firmly espoused in principle, I’m not convinced that the concept is well understood and, therefore, misses the mark in execution (this statement is based on direct observation of dozens of teams who are doing their best to follow Agile principles and continually improve). The reason for this is straightforward: Agile is being driven by IT. Our focus is on “working software.” Yes, “working” should include the concept of providing real value in the real world, but does it? How do we know? Are we utilizing objective measurements to show how real customers are using the product in the real world? Or are we satisfied validating this through the tacit approval of a Product Owner?
More importantly, is anyone stopping to ask these questions before we get started? I am continually surprised by how many software projects are given the green light or continue to live without anyone asking the hard questions: how will we justify the significant expense incurred to create and maintain this? How many users will actually use it? Will those who we expect to use this find it valuable? What problems will it solve? What problems will it create? How can we know the answers to these questions before we have a product for someone to use? It strikes me that there are very few products who could get away with making it to production without answering these questions. I think the days of software products getting away with it are numbered.
Let me pose a simple question: how many non-IT business professionals can you list who are making a significant contribution to the Agile movement? How many Product Managers? Product Marketers? Corporate Executives? I know my circle is small, but I can’t think of any. It seems to me that if we were truly engaging “the Business side of the house” that they would eventually have a significant presence as speakers at conferences, authors of books on Agile and the like. Yet the Agile landscape is still dominated by geeks.
This is not to say that Agile has failed, but I do think Agile can only go so far: it can only solve certain problems in its current state. Agile has performed splendidly, moving us away from a draconian focus on process, but I am not convinced it can take us all the way to where we need to be: focused on providing real value in the real world. IT cannot lead us there. We desperately need someone without our blind spots to show us the way.
Fortunately, many in Agile circles are already wrestling with this issue and I intend to delve deeper into some proposed solutions in my next article.
So what do you think? Am I completely off-base? Are we already there and I’m just late to the game? As always, your comments are welcome!
Permalink
10.28.08
Posted in Agile, Iterative Development, Journal, Software Development, Teams at 9:52 am by Pablosan
Back in the mid-nineties, having been introduced to Apple Newtons, Palm Pilots and Wacom’s new tablet-is-the-screen technology (I don’t remember the official name), I started dreaming. It had been several years before this that a conversation about computers with my dad ended with his comment “I’ll use a computer when it starts speaking my language!” He has been using computers for a long time now, so I’m pretty sure he has since lowered his standards. While all of this was swirling around out there like the “breeze of democracy”, I came up with the perfect byline for a PDA: “As easy to use as a piece of paper.”
I’ve been reminded of this tag-line twice in the last week. The first time was while attending a debrief meeting with a company who had unsuccessfully demoed their ALM tool to the company with whom I am currently consulting. We provided them with some valuable feedback, with one of the main complaints being the product’s complexity. I asked them why their product, which is intended for Agile teams, did not more resemble a Card Wall. There are several products out there that do: GreenHopper is an excellent plug-in for JIRA and there is Mingle, which is fairly new, has a ways to go, but is off to a great start.
The second time I was reminded of my tag-line was yesterday, while interviewing with Rally Software here in Boulder. We didn’t go into much detail (we only had 30 minutes), but I shared with them my concern that the current crop of software tools, with a couple exceptions, seem to take what was supposed to be a light-weight, very fast and effective practice, and turn it into an incredibly complex piece of software. They shared with me that, using feedback from their users, they were finding ways to simplify their product. Kudos to them!
So, if using Index cards and slapping them up on a wall is so great, why use a software tool? Here are my answers:
- Don’t use a software tool. Use a Card Wall.
- If your team is not co-located (meaning not everyone on the team will be able to see a physical Card Wall), divide up the project in such a way that you have several, co-located teams that can each have their own Card Wall.
- If your teams are not co-located and you have a need to aggregate data across your teams, be ruthless in your process to find the most light-weight possible approach to gathering that data.
I understand the need for Agile ALM tools. If you’re like me, you’ll view them as a necessary evil. The last thing you want to do is force your teams back into the Chisel-and-Stone era. Even though it’s probably impossible, be unrelenting in your pursuit to make the tools you use “As easy to use as a piece of paper.”
Permalink
08.18.08
Posted in Agile, Iterative Development, Software Development, TDD at 8:01 pm by Pablosan
See, I told you I’d get back on track when I wasn’t so distracted! My latest Erlang article, Strings ‘n’ Things is up on CodeNotes. I ran into a little trouble with character encodings. I wanted one of the tests to demonstrate the extended characters that Erlang supports (ISO-8859-1, a.k.a. Latin-1) and they weren’t getting encoded properly by my article generator application. After some digging, I figured out that I did not have vim configured correctly (everything was UTF-8 except for vim, which can be fixed by adding “set encoding=utf-8″ to your .vimrc file, btw). Once that was fixed, I was back in business.
My primary lesson-learned in this coding session is that Erlang is probably not the best choice if you need to deal with multiple character encodings, or even if you’re looking to support UTF. I don’t see that as a significant problem, as it would be quite effective to use Erlang for “heavy lifting” tasks, and relegate character encodings to something much friendlier… like Ruby (especially Ruby 1.9).
This latest revelation almost caused me to look for a different functional language… almost. I’m totally sold on Erlang’s approach to concurrency, though. It is dead simple and avoids the mess of multi-threading and shared memory. I know it’s not the only language out there that takes the message-passing/no shared memory approach, but I’m pretty sure any other language I look into will have it’s share of peculiarities.
This is the last article covering the basics of Erlang, and it was finished just in time. I’m ready to move on to some heavier stuff.
Permalink
08.12.08
Posted in Agile, Iterative Development, Software Development, TDD at 10:02 pm by Pablosan
Objective-C’s, X’es and O’s – Part 2 is now up on CodeNotes. This article finishes up my exploration of Test-Driving a Tic-Tac-Toe model in Objective-C. There is still more that could be done with the model, but I needed to stop somewhere.
The test class is about 2.5 times larger than the production class, which seems about right for this type of problem. The resulting test coverage is comprehensive, and the code quality seems high to me.
The other thing I noticed is that, since I show all of the source code with every change, the articles can get a bit long. I’m considering changing the format so that just the changed/added lines are shown, but I think seeing the entire class/interface/whatever improves comprehensibility.
This has been a good break from Erlang for me, but I’m eager to get back to my favorite functional language. So look for a new Erlang article soon!
Permalink
08.11.08
Posted in Agile, Iterative Development, Software Development, TDD at 5:32 pm by Pablosan
Objective-C is… interesting. There are some things I really like about the language. The message-passing metaphor works really well for me: I like it a lot. I also like the “annotations” that help distinguish the interface from the implementation (it seems like syntactic sugar, but I still find it helpful). I was disappointed by the inability to use a static const for the size component(s) in array initialization: being forced to use a #define… well, hurt… just a little (as described in my previous Objective-C post).
OCUnit seems to be a decent implementation of the xUnit framework as well. Unfortunately, they didn’t provide convenience Assert methods that don’t require a comment, so I felt like having comments on every single Assert cluttered up the tests just a bit. That could be easily fixed, but I can’t quite figure out the current state of the OCUnit framework. The Sen:te site hasn’t been updated in over three years, so I’m afraid OCUnit has been swallowed by Apple. And once something has been swallowed by “Mr. Proprietary”, it’s untouchable.
Test-Driving a Tic-Tac-Toe model is a blast: I think it should become a Code Kata. The article, Objective-C’s, X’es and O’s, Part 1 will be concluded with a follow-on article very soon. The article is plenty long, but there were still a few more things to implement to complete the model.
One final request: it would be really helpful if someone with extensive Objective-C experience could critique my use of the language. I feel like I have a fairly good grasp of the language, but it wouldn’t surprise me if I’m missing things.
Enjoy!
Permalink
08.04.08
Posted in Agile, Iterative Development, Software Development, TDD at 6:54 pm by Pablosan
My latest trek into Erlang territory, List Processing: Not Lisp, is up on CodeNotes. Lists are one of several things in Functional Languages that tend to trip people up. They look like arrays, but they’re not. At first they seem inflexible, but they are very powerful constructs with a pretty simple interface.
I have one more article to write covering the basics of Erlang. I’m actually looking forward to being done with this phase so that I can get into some real TDD examples in Erlang. I’m anxious to see how well TDD holds up to the strain of test-driving functional programming.
As far as a Go bot, I am leaning heavily toward using Erlang, but it’s going to be awhile before I’m ready to tackle that particular challenge. Baby steps… baby steps.
Permalink
08.01.08
Posted in Agile, Go, Iterative Development, Software Development at 7:17 pm by Pablosan
Don your crash helmet and fasten your seatbelt: I’m about to attempt my first foray into computational complexity. Women who are pregnant, children, and those with weak constitutions may need to leave the room or, at the very least, avert their eyes. Here we go!
The game of Go, which I’ve recently picked up (I’m “Pablosan” on DragonGo, if any of you would like to hit me up for a game), is fascinating for many reasons. What really caught my attention, though, is that, in spite of decades of trying, no one has yet to create a computer program that can beat the top amateur-level players, let alone professionals. While the rules of Go are quite simple, the strategies of Go are vast. Go is the epitome of “Minutes to learn; a lifetime to master.” One could spend their entire life studying Go and still leave much of the game undiscovered.
That sounded like a good challenge to me. So I spent a little time researching Go “bots”, subscribed to a mailing list, etc. and quickly found myself nose-to-nose with Computational Complexity. Yikes! I ran across this website, which lists the game of Go as EXPTIME-complete, and that quickly introduced me to Descriptive Complexity – “a branch of finite model theory, a subfield of computation complexity theory and mathematical logic”; the codification of which is credited primarily to Neil Immerman, Ph.D, a graduate of Yale and Cornell, a professor at UMASS, and winner of the 1995 Gödel Prize in theoretical computer science. To put it plainly, I had chosen a problem that landed squarely in the “nearly impossible to solve” category, and ended up way out of my league! At this point, I realized that I was attempting to swallow the elephant whole.
I pride myself in my acute problem-solving ability, and my primary approach to solving difficult problems is to break them down into smaller problems (which is one of many reasons why I’m sold on TDD). And the game of Go already has this sort of built-in. Though a standard Go board is a 19×19 grid, it is quite common for beginners to play on a 9×9 grid. For those writing programs to play Go, 9×9 is currently a very popular grid size, and even 7×7 boards are used. Why? Because this greatly reduces the problem complexity. Even on just a 2×2 board, the number of possible game positions is 3^4 or 81 (3 states per position and 2*2 positions). On a 7×7 board the number is already astronomical at 2.39e+23. Attempting to calculate the number of positions for a full-size board on the iPhone’s scientific calculator… well, broke it… okay not really, but it did display “Error”.
So deciding that keeping my sanity was preferable to starting off in the deep weeds, and wanting to see what I could accomplish with my shiny, new iPhone SDK, I thought I’d set my sites just a tad lower… on Tic-Tac-Toe! No wait! There are actually similarities between the games. Really! Both are played on a grid, and both have a possible three states per position. In both games, the players alternate placing markers on the board. The primary difference that really complicates Go (other than the sheer size of the playing field) is that markers (stones) can be removed (captured). The main benefit to me of downscaling from Go to Tic-Tac-Toe is that the problem domain becomes very manageable. Once I finish modeling Tic-Tac-Toe, I will have taken one, tiny bite out of the elephant named “Go.” My next, tiny bite will be to model Go on a 2×2 board.
At this rate, I may have a Go bot ready to compete on 9×9 boards sometime after retirement, which is currently scheduled around my 90th birthday; sometime in the ’50′s.
Permalink
07.31.08
Posted in Agile, Iterative Development, Software Development, TDD at 7:24 pm by Pablosan
My latest TDD & Erlang article is up on CodeNotes: Atomic Tic-Tac-Toe. I know I’m favoring Erlang right now, and that’s because I’m simply having too much fun! I have several ideas, both for Java and Objective-C and I’ll get to them… hopefully soon. For now I’m trying to make the best of the momentum I have in learning Erlang: striking while the iron’s hot, as the old adage goes. This latest article starts getting into the good stuff, as it deals with atoms and tuples.
Additionally, I currently have Tic-Tac-Toe on the brain. I chose it for my first iPhone app, but the app keeps getting sidetracked as I dig into Test-Driving a Tic-Tac-Toe model. I am surprised at just how fascinating this coding problem is. Jeff Langr and I have paired on this problem in Java a couple times, and you can read a bit about that on his blog.
I’ve been trying to judge whether or not my coding example articles are sized appropriately: long enough to cover some ground, but not so long that they become hard to follow. Any feedback on that, or any other critiques of my meanderings is always appreciated.
Thanks for tuning in and I hope you enjoy the new article!
Permalink
« Previous entries Next Page » Next Page »
