And - the JBoss ESB book is on Kindle too:
http://www.amazon.com/JBoss-ESB-Beginners-Guide-ebook/dp/B0071LKMTU/ref=dp_kinw_strp_1?ie=UTF8&m=AG56TWVU5XWC2
Wednesday, January 25, 2012
The JBossESB Book is officially published!
It's available at Packt now! http://www.packtpub.com/jboss-esb-beginners-guide/book
And at Amazon: http://www.amazon.com/JBoss-ESB-Beginners-Guide-DiMaggio/dp/1849516588/
A review of the book is here: http://rickwagner.blogspot.com/2011/10/book-review-for-jboss-esb-beginners.html
Thursday, January 19, 2012
Embracing the Sliding Window of Doubt
We
create schedules for many different things but generally for the same
reasons - to enable us to determine when in the future a task will be
completed, to enable us to allocate time and money and resources to
perform that task, and to enable other organizations to coordinate their
future actions.
In other words, we create schedules in an attempt to predict the future.
But, why do we get it wrong so often?
Why is it that, in spite of how precisely we plan our tasks and try to take into account what might go wrong, so many project schedules miss their original target completion date?
Why did Boston's famous "Big Dig" road and tunnel construction project (http://en.m.wikipedia.org/wiki/Big_Dig_(Boston,_Massachusetts)) slip from being a $3 billion project to a $15 billion project?
Part of the reason may be simply that it is a difficult task to create a schedule that can accurately predict the future. Another part of the reason may be that people, as Frederick Brooks observed in "The Mythical Man-Month," (http://en.wikipedia.org/wiki/The_Mythical_Man-Month) are eternal optimists. We always think that "this time" things will go well, and we won't have any schedule-related problems. As a result, we fail to plan for everything that may possibly "go wrong."
But, there may be another reason. Maybe we cause our own imprecision by trying to be too precise. In other words, maybe we set ourselves up for failure and make schedule "slips" a self-fulfilling prophecy.
Which leads me to a golf story. An historical golf story, that is.
When he was asked to explain his surprising lack of success when he tried to play competitive golf a few years after his retirement at the early age 28, golf great Bobby Jones attributed it to his misguided attempt to achieve a level of precision and consistency greater than he had ever had during his best playing years. Who was Bobby Jones? The Tiger Woods of his era - back when gofers wore ties.
Maybe it's a bit like that with scheduling. Do we doom ourselves to always creating schedules that are missed by trying to achieve a target that is so precise that it can never actually be hit?
I've been thinking lately that a better approach for scheduling a large, long running, and complex project schedule is to not attempt to target a single "hard" and unchanging target completion date (for example, "our project will be completed on May 23rd at 09:00, Eastern Daylight Time"), but rather but rather to target a window of time in which the project will be completed, "slide" that window closer or further away and have it expand and contract based upon your level of confidence according to the current conditions of the project, all in the context of the the current project conditions.
This window can be thought of as the "sliding window of doubt."
OK, this idea of a "sliding window of doubt" raises a couple of questions:
What are the potential advantages of a sliding window approach?
One of the best aspects the sliding window approach is that it of scheduling a project schedule with a sliding window is that it converts the reassessment of the schedule from a reactive to a proactive task. Reassessing the schedule, and possibly sliding the project completion window is not an aberration or exception, that is only done as a reaction to a problem. Instead, it is a ongoing part of the management of the project. These re-assessments will become increasingly more accurate estimate as the project proceeds as the more you learn about the problems that a project faces during its development the better you can predict its future. As a result, you will have more accurate estimates (the window only shrinks when your confidence in the project's ability to meet its schedule increases) based on the re-assessments, and the project team will have constant access to up-to-date schedule information.
Another advantage of the sliding window approach is the flexibility that it provides the project team. The "consumers" of the schedule include the project team members themselves as well as the consumers (other project teams or end user customers) of the project deliverables, as these consumers must create their own schedules, for their own deliverables, all of which depend on your project and its schedule. With a rigid, single-date based schedule, even small changes can effect that date, and cause disruption (or maybe even panic) to dependent project and customer schedules.
Also, by building into the project plan the ability to slide the release window,people who might otherwise delay in providing bad news that would affect the schedule, out of fear of a "shoot the messenger" situation, may be more inclined to make that news available to the team sooner.
How is a "sliding" window any different from defining a more convention schedule, and then "slipping" the target dates?
The difference really comes down to what controls the schedule changes.
As we discussed just a moment ago, the constant reassessment of the schedule, where the level of doubt is re-evaluated based on the current project conditions, is a proactive task. Your project team is in more control of its fate with the sliding window approach. Also, remember that these re-assessments are not only performed when there are problems to be resolved, they are also performed when things are going well. Accordingly, while the window can slide out in response to unexpected problems, it can also move in if the project is progressing better than the original plan.
So, to sum up, when you are faced with the challenge of devising a schedule for a large, complex, long-running project, it's worthwhile to consider the "sliding window of doubt" as an approach to scheduling key milestones and release dates. At its core, this approach provides you with the flexibility to refine the schedule over time, and perform proactive schedule reassessments, that will result in the window sliding closer or further away, and expanding or contracting, all based the most up-to-date information available.
We started this discussion by asking - "Why does every project miss its target milestones and completion dates?"
Maybe the the real question that we should ask ourselves is: Why does every project schedule seem to miss its target completion date?
If the dates were rigidly defined, and the project team never re-assessed those dates as the project proceeded and unanticipated problems were encountered, then the dates were probably never achievable in the first place. What the project needed was a sliding window of doubt!
Postscript - the presence of doubt or the absence of confidence?
It's interesting how your occupation can color your view of the world. If you work in engineering (and especially if you work in software testing) you tend to look for the negative side of things. In other words, you look for what might go wrong. People engaged in sales or marketing tend to have a rosier view of things. For example, when I described the sliding window of doubt to a marketing person, she replied:
"Oh, you mean the sliding window of confidence!"
I guess she was correct, as confidence is the inverse of doubt!
(Special thanks to John Graham (http://osmusings.blogspot.com/) for his inspiration for this post.)
In other words, we create schedules in an attempt to predict the future.
But, why do we get it wrong so often?
Why is it that, in spite of how precisely we plan our tasks and try to take into account what might go wrong, so many project schedules miss their original target completion date?
Why did Boston's famous "Big Dig" road and tunnel construction project (http://en.m.wikipedia.org/wiki/Big_Dig_(Boston,_Massachusetts)) slip from being a $3 billion project to a $15 billion project?
Part of the reason may be simply that it is a difficult task to create a schedule that can accurately predict the future. Another part of the reason may be that people, as Frederick Brooks observed in "The Mythical Man-Month," (http://en.wikipedia.org/wiki/The_Mythical_Man-Month) are eternal optimists. We always think that "this time" things will go well, and we won't have any schedule-related problems. As a result, we fail to plan for everything that may possibly "go wrong."
But, there may be another reason. Maybe we cause our own imprecision by trying to be too precise. In other words, maybe we set ourselves up for failure and make schedule "slips" a self-fulfilling prophecy.
Which leads me to a golf story. An historical golf story, that is.
When he was asked to explain his surprising lack of success when he tried to play competitive golf a few years after his retirement at the early age 28, golf great Bobby Jones attributed it to his misguided attempt to achieve a level of precision and consistency greater than he had ever had during his best playing years. Who was Bobby Jones? The Tiger Woods of his era - back when gofers wore ties.
Maybe it's a bit like that with scheduling. Do we doom ourselves to always creating schedules that are missed by trying to achieve a target that is so precise that it can never actually be hit?
I've been thinking lately that a better approach for scheduling a large, long running, and complex project schedule is to not attempt to target a single "hard" and unchanging target completion date (for example, "our project will be completed on May 23rd at 09:00, Eastern Daylight Time"), but rather but rather to target a window of time in which the project will be completed, "slide" that window closer or further away and have it expand and contract based upon your level of confidence according to the current conditions of the project, all in the context of the the current project conditions.
This window can be thought of as the "sliding window of doubt."
OK, this idea of a "sliding window of doubt" raises a couple of questions:
What are the potential advantages of a sliding window approach?
One of the best aspects the sliding window approach is that it of scheduling a project schedule with a sliding window is that it converts the reassessment of the schedule from a reactive to a proactive task. Reassessing the schedule, and possibly sliding the project completion window is not an aberration or exception, that is only done as a reaction to a problem. Instead, it is a ongoing part of the management of the project. These re-assessments will become increasingly more accurate estimate as the project proceeds as the more you learn about the problems that a project faces during its development the better you can predict its future. As a result, you will have more accurate estimates (the window only shrinks when your confidence in the project's ability to meet its schedule increases) based on the re-assessments, and the project team will have constant access to up-to-date schedule information.
Another advantage of the sliding window approach is the flexibility that it provides the project team. The "consumers" of the schedule include the project team members themselves as well as the consumers (other project teams or end user customers) of the project deliverables, as these consumers must create their own schedules, for their own deliverables, all of which depend on your project and its schedule. With a rigid, single-date based schedule, even small changes can effect that date, and cause disruption (or maybe even panic) to dependent project and customer schedules.
Also, by building into the project plan the ability to slide the release window,people who might otherwise delay in providing bad news that would affect the schedule, out of fear of a "shoot the messenger" situation, may be more inclined to make that news available to the team sooner.
How is a "sliding" window any different from defining a more convention schedule, and then "slipping" the target dates?
The difference really comes down to what controls the schedule changes.
As we discussed just a moment ago, the constant reassessment of the schedule, where the level of doubt is re-evaluated based on the current project conditions, is a proactive task. Your project team is in more control of its fate with the sliding window approach. Also, remember that these re-assessments are not only performed when there are problems to be resolved, they are also performed when things are going well. Accordingly, while the window can slide out in response to unexpected problems, it can also move in if the project is progressing better than the original plan.
So, to sum up, when you are faced with the challenge of devising a schedule for a large, complex, long-running project, it's worthwhile to consider the "sliding window of doubt" as an approach to scheduling key milestones and release dates. At its core, this approach provides you with the flexibility to refine the schedule over time, and perform proactive schedule reassessments, that will result in the window sliding closer or further away, and expanding or contracting, all based the most up-to-date information available.
We started this discussion by asking - "Why does every project miss its target milestones and completion dates?"
Maybe the the real question that we should ask ourselves is: Why does every project schedule seem to miss its target completion date?
If the dates were rigidly defined, and the project team never re-assessed those dates as the project proceeded and unanticipated problems were encountered, then the dates were probably never achievable in the first place. What the project needed was a sliding window of doubt!
Postscript - the presence of doubt or the absence of confidence?
It's interesting how your occupation can color your view of the world. If you work in engineering (and especially if you work in software testing) you tend to look for the negative side of things. In other words, you look for what might go wrong. People engaged in sales or marketing tend to have a rosier view of things. For example, when I described the sliding window of doubt to a marketing person, she replied:
"Oh, you mean the sliding window of confidence!"
I guess she was correct, as confidence is the inverse of doubt!
(Special thanks to John Graham (http://osmusings.blogspot.com/) for his inspiration for this post.)
Sunday, December 25, 2011
Software Testing...and Ketchup
When you're assembling the elements of a software test "toolbox" you'll probably start with tools such as:
- Test organization/execution frameworks (such as JUnit)
- UI automation frameworks - (such as Selenium for web-based products)
- Web Service testing - (such as soapUI)
- Memory use profiling - (such as jProfiler)
- Defect tracking (such as Bugzilla)
But, you might also need to add a little ketchup.
I had just completed translating a set of human tasks to automated UI test scripts. After having run the tests in pieces and then assembled the pieces into a final revision, I thought I was finished. The test however, continually failed.
After debugging the problem, I discovered that the failure was not due to a test coding error. As part of its initialization, the test had to run a "zip-up" a directory into a .zip file, but the test was unable to locate the "zip" binary file in the /usr/bin directory. This made no sense, as both the directory and the zip binary were clearly present on the test system. The problem was also not due to file or directory permissions as the script was able to successfully access other utilities, that were located in the same directory and were configured with the same permissions.
It took me a while to determine that the cause of the script failing was not its ability to access or execute a utility in /usr/bin, the problem was simply the number of files in that directory.
The script, remember, was a UI test script. In order for the script to invoke the zip utility, it located the utility's binary file with a UI-based file system browser. The large number of utilities in the directory (over 2000) caused delays in the system's ability to populate the file system browser with the directory contents. The test script had the misfortune of depending on a utility, the name of which began with the letter "z" and the logic of the script was such that it assumed that the zip utility would always be displayed and could always be invoked.
My initial fix for the problem was to add a sleep statement to the script to give the file system browser the time it needed to display the entire directory listing. I later modified this to be more flexible and avoid unnecessary delays by querying the file system browser multiple times while it waited for the full directory contents to be displayed.
Once the test script was complete and running cleanly I complained about the timing issues to a co-worker. He was more amused than sympathetic and replied to me: "Well, what did you expect? You forgot the ketchup! Automation is like a hamburger, it needs some ketchup. That's what sleep statements are to automation. They are the ketchup in the recipe!"
On a practical note, the "ketchup" delay was necessary as, unlike a human being, who would pause by reflex to wait for visual feedback, my test script was originally designed to "plow ahead" at top speed, regardless of whether the UI elements on which it depended were available.
And on that delicious note, it's time to wrap up 2011! Happy 2012 everyone!
As much as I'd like to take credit for thinking up the ketchup concept, I can't. I owe it all to my friend and colleague Martin! Diky moc (many thanks) Martin!
Wednesday, December 7, 2011
JBoss Survey (and a discount) at Packt
Packt, the nice folks publishing the JBoss ESB Begineers' Guide later on this month, have a new survey for JBoss users and books.
The survey is here: http://snipurl.com/21212r0
Packt is overseeing a community survey for JBoss users to find out what support they need to aid and enhance their JBoss experience. Packt want to make sure they are making the right offers to all JBoss users and are providing what they need and want.
The survey is about all of JBoss projects (Drools, AS, jBPM and more). The questions will help to provide a snapshot of how the community finds support, how they self-educate, help each other and what information they need now.
As Packt think the results will be of genuine interest to the JBoss community, the results of the survey will be published.
Not only that but every JBoss user that completes the survey will receive a 25% discount off their next JBoss eBook purchase from Packt.
The survey is here: http://snipurl.com/21212r0
Packt is overseeing a community survey for JBoss users to find out what support they need to aid and enhance their JBoss experience. Packt want to make sure they are making the right offers to all JBoss users and are providing what they need and want.
The survey is about all of JBoss projects (Drools, AS, jBPM and more). The questions will help to provide a snapshot of how the community finds support, how they self-educate, help each other and what information they need now.
As Packt think the results will be of genuine interest to the JBoss community, the results of the survey will be published.
Not only that but every JBoss user that completes the survey will receive a 25% discount off their next JBoss eBook purchase from Packt.
Thursday, September 29, 2011
The JBoss ESB Book is now in Packt's RAW Program
The soon-to-be-published (by Packt) JBoss ESB Beginner's Guide is now in the Packt "RAW" program - so that the book can be purchased pre-release - and chapters are provided as they are completed.
http://www.packtpub.com/jboss-esb-beginners-guide/book
Monday, September 12, 2011
Subscribe to:
Posts (Atom)