By Topic

In methods we trust?

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$33 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)
L. Hohmann ; SmartPatents Inc., USA

The degree to which you trust your environment-including co-workers, software tools and systems-has a dramatic impact on the performance of your entire software development team. If you can't trust someone during a code review, what are the chances the code review will be any good? I've become increasingly aware of another aspect of trust: the trust of a method. A method is a disciplined approach to problem solving that produces one or more well-defined outcomes. There appear to be two philosophies when it comes to trust and methods. One camp soundly rejects methods as a basis for trust: the only valid approach to problem solving is to identify specific problems systematically in their environment and solve these problems, one by one. The other camp takes the opposite approach, performing every process step by preparing all of the models (and other outcomes) defined by their method. The question is not whether you build software according to a process, but whether you trust the process you use. Do you trust your development process to generate accurate schedules? Do you trust it to generate high-quality, easily maintainable source code? Do you trust that your process will generate highly usable systems?.

Published in:

Computer  (Volume:30 ,  Issue: 10 )