1. From the article, the clear winners are the customers and users.
While it is important to consult with customers during the design of
any product, when one is trying to design a single component to
satisfy a wide range of customers, gathering their requirements and
allowing them to reach component function compromises are critical.
Customers are far more likely to accept a product that is not 100%
tailored to them if they have been involved in its development and
understand the trade-offs that were made.
The other winner, at least in the long term, should be the company
developing the software. In theory, component reuse should lead to
more efficient product development and many fewer bugs than 100%
custom code for each product (lower prices resulting from development
efficiency and fewer bugs also benefit customers). This occurs
because less code overall has to be written for each product and, once
a component is debugged, it remains debugged no matter how many times
it is reused.
The biggest loser from the new process are the developers. They lose
creative control over a significant portion of their work and are
required to interact far more with code written by other people. The
article notes their fear of loss of professionalism. Their high
degree of knowledge of legacy code may also become much less valuable
within the organization. Fewer highly skilled developers and fewer
developers overall may be needed under the new development approach.
Product managers and line managers also suffer, at least in the short
term. The article notes an initial loss of efficiency in product
development activities because of adoption of the new approach. Line
managers have to become accustomed to working with software that is
not 100% custom tailored to them and adapting business processes to
fit the software instead of vice versa.
In general, people accustomed to the old way of doing things are at a
disadvantage and may feel uncomfortable. They may try to sabotage
adoption of the new process. In extreme cases, the company may feel
the need to replace some portions of its workforce with new people
with new ways of thinking, causing some people to lose their jobs.
2. Some companies clearly did a better job of managing their
components repository than others. Also, some businesses may be
better addressed by common components than others, although one has to
question the belief of the company in Case 1 that there never were any
components in the repository that could meet their customer's needs.
Usage of tools like Rational Rose greatly improved the efficiency of
component reuse and modification and limited the number of components
that had to be built from scratch. Also, gaining comfort with
third-party components also improved development efficiency, but also
required more flexibility from the end user to adapt their business
process to the software than does a custom built system. Abandonment
of the "not invented here" syndrome and adoption of tools to better
manage third-party and in-house component libraries, along with
creative approaches for component reuse and modification, would
improve the effectiveness of this approach to software development.
3. Having worked in software development for a significant period of
time, I found the so socio-technical design approach to be a useful
tool for solving real-world problems. I completely agreed with the
statement that the "... major cause of most software failures is the
people rather than technical issues." Attempts to develop products
without taking the people-factor into account will at best result in a
suboptimal product and at worst result in failure. Political
considerations and incentives that are aligned against the fundamental
objective of developing a product that meets customers' needs at the
lowest cost have to be explicitly examined and addressed.
4. The next logical steps I identified would be to first of all align
the incentives of the developers and product managers with the
adoption and use of component-based design. Specifically, developers
and product managers should be rewarded for reuse and modification of
existing components, along with successful development of new
components that become widely reused. Second, a business process
oriented around mapping customer requirements to the existing and
third-party component libraries rather than operating with the
assumption that customers' needs can only be met by custom development
should be implemented. Third, to the extent that the company has
in-house customers, those customers need to be educated as to the
value of component-based development and encouraged to adapt their
business processes to the software instead of demanding custom
development to fit their particular existing business process.
Fourth, the company must become adept at acquiring and managing its
external customers' requirements and preparing them to accept a
generic component instead of a custom tailored component whenever
possible.
I hope you have found the above analysis helpful. Please request
clarification if needed.
Sincerely,
Wonko |
,
0 Comments
)