|
Re: Hidden Variables
|
Posted: Jul 11, 2006 9:33 AM
|
|
> I think we are missing the point completely. When you look > at the big picture, the real problem is that our so called > software engineering discipline is not a proper > engineering discipline. More specifically, we don't have a > proper component model for software. > > As stated by "Reuse-Based Software Engineering" book ( > Mili et al), due to repeating functionality, up to %85 of > a typical application can be built by reusable components > (%15 generic + %65 domain specific). Which simply means > that if we had a proper component model, most of our > applications would be built, not developed, by the > assembly of pre-built software components. > > Tools and technologies that we are using today are still > too low level that they put too much responsibility on > developers in terms of learned skills, talent, experience > and training in order to produce reliable systems in > predictable time scales. Instead of raising the > abstraction level of the tools and the technologies that > we use, we are still trying to increase the (skill) level > of developers with numerous methodologies. And this, in my > opinion, is the wrong direction to take. I will try to > make myself clear with the following example. > > If we pick the assembly language as the tool and ask the > entire developer population of the world to produce a > non-trivial application, I think only 5 or 6 percent of > them will be able to produce a decent enough usable > system. This shouldn't come as a surprise since it > requires so much concentration, talent and skill to get it > right with such a low level tool. But, if we pick a much > higher level tool instead, Smalltalk, Ruby or Python for > instance, this percentage will be much higher; probably > more than 60 or 70 percent. (Please note that these > figures are rough guestimates in order to make my point, > nothing to be taken seriously). By raising the level of > technology we can get rid of the differences among > developers and become less demanding on the level of skill > that we expect from them. It should be clear from this > example that by raising the level of the tool, we gain > more ground and achieve much higher levels of > productivity. > > Which direction would you take? Would you stay with the > assembly language and try to increase the level of > developers by methodologies and training, instead of > creating tools that provide higher levels of abstraction? > No matter how agile or extreme our methodology is, there > is no way we can achieve the same results that we could > obtain with higher level technologies. > > Again, if we take these %60-70 Smalltalk, Ruby or Python > applications and look for reliable, flexible and > maintainable applications that are build out of > independent, reusable, black-box components, the > percentage will not be more than 5 or 6 percent. The > reason for that is even our latest or best technologies of > today, do almost nothing to help the developers produce > independent, reusable, replaceable, black-box components > out of which we can assemble most of our systems. > > That is why, instead of wasting time with the human > factor, we should try to create higher level technologies > that will enable developers produce higher quality proper > software components regardless of their level of skill, > experience and training. And speaking from experience (I > am doing research on the subject for number years), this > is not an impossible task. It is just that most of the > brain power is concentrated on the wrong or less effective > solution.
IMHO, that doesn't make the human factors go away at all, it just scuttles them to another corner.
Re the componentization of software, I think there are economic and physical reasons why componentization will never be a panacea. And, we can't say that it hasn't been attempted; it's been attempted countless times.
|
|