Monday, March 27, 2006
Becoming Enterprise Ready
Danny a dutch blogger said something intriguing regarding software development in Ruby that should be considered...
I encourage folks to not only read his post but to provide some amplification to it. I figured that there was one aspect that I wanted to provide my own perspective into which of course I will be setting myself up to get attacked again. The notion of prototyping in front of a customer using either Ruby or Java for that matter by a slick developer should be discouraged for a variety of reasons, including but not limited to:
A couple of weeks ago, I learned that Pratt & Whitney, a manufacturer of aircraft engines started to source most of its work from other countries at the expense of local machine shops who were savage in not only increasing quality over time but also in increasing productivity of its workers. The executives at Pratt & Whitney figured out that it was cheaper to have the same part made by several different manufacturers at the same time, choosing the one that was best produced out of the bunch and throwing out the rest. Will IT also follow this same path?
| | View blog reactionsI encourage folks to not only read his post but to provide some amplification to it. I figured that there was one aspect that I wanted to provide my own perspective into which of course I will be setting myself up to get attacked again. The notion of prototyping in front of a customer using either Ruby or Java for that matter by a slick developer should be discouraged for a variety of reasons, including but not limited to:
- In many shops, business customers will be esctatic to have IT folks show them there work in a rapid manner, but IT folks have somewhat of a fidicuary duty to maximize the time not spent by the business community on IT related issues and let them focus on their core competency. No, this doesn't justify current approaches in this regard, but it doesn't also mean that we should be making them watch us
code. - There are simply better ways to prototype nowadays. Minimally, the business person is interested in seeing that IT understands the business process. This can be captured using any of the BPM modeling tools. Likewise, there is a new breed of emerging software category known as simulation software. Maybe the community should check out offerings such as iRise and its competitors?
- A coded prototype is more functionally rich than the static prototype. The coded prototype, however, makes a long development cycle even longer, because instead of reducing the amount of coding overall, it adds to it. Furthermore, coded prototypes are difficult to change, remain in the domain of the IT specialists and cannot be managed by the business user.
A couple of weeks ago, I learned that Pratt & Whitney, a manufacturer of aircraft engines started to source most of its work from other countries at the expense of local machine shops who were savage in not only increasing quality over time but also in increasing productivity of its workers. The executives at Pratt & Whitney figured out that it was cheaper to have the same part made by several different manufacturers at the same time, choosing the one that was best produced out of the bunch and throwing out the rest. Will IT also follow this same path?
