|
|
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.
|
|
Previous Topic
