Recently, a reader, commenting on my last post about Sure Step, pointed me to an article by Karl E. Wiegers
“Read My Lips: No New Models!” I initially responded to the comment, but I figure the comments aren’t read as often as posts, so I decided to blog it.
It’s doubly funny that the reader is using Dr. Wiegers to devalue and dismiss Sure Step: firstly, the article has really nothing to do with implementation methodologies at all, and secondly, when I delivered Sure Step training at WinDays pre-conf earlier this year, I gave to each attendant a copy of Karl E. Wiegers’s latest book “Practical Project Initiation”—at the time it was the best book available that matched both the message of my training and the point of Sure Step as a methodology.
Methodology is a tough topic. There are good methodologies, there are bad methodologies, there are good methodologies gone bad. Methodology is not a silver bullet, it won’t just make any problems disappear, and is hardly ever the single source of success or failure. But a methodology can be a major contributor to success. I could put it this way: you stand much better chances of success if you apply a methodology, then if you don’t. With something as critical as an implementation of business software, methodology is a key success factor. According to Jim Johnson of Standish Group, it’s number nine on their ten identified most important success factors.
Hint: this is a post for developers, and mostly junior developers, those who are still learning how to code properly. I know, I promised not to blog about stuff like this, but I simply couldn’t help this time.
A friend of mine has asked me for help.
“There is this C/AL function I had to rewrite, now I end up with 106 BEGINs, and only 105 ENDs. Do you have any idea how to find where this missing END belongs?”
I had to update this post a little bit, see below for the details, but the killer feature had to go 🙁