Showing posts with label Programmers. Show all posts
Showing posts with label Programmers. Show all posts

Software Design and Programmers 3


The scary part is that the software engineering texts that Whitaker and At kin so skillfully deride are the standard texts used in college software development courses. For example, Software Engineering: A Practitioners ApproachMcGowan Hill’s best-selling software engineering text, does not have a single program listing. Software Engineering: Theory and Practice, Prentice Hall’s bestseller, does dedicate 22 pages to coding. [Whitaker, 2002, p. 110]
One approach that has arisen as an alternative to the software engineering approach is the craft-based approach, which DE emphasizes complex processes, specialization, and hand-offs.1 Extreme Programming is an example of a craft-centric methodology. Extreme Programming, and related techniques such as re factoring and "test first design," arose from the work Small talk developers Kent Beck and Ward Cunningham did together. According to Pete McBride in Questioning Extreme Programming, "The idea that the source code is the design was widespread in the Small talk community of the 1980s." Extreme Programming has at its core the idea that the code is the design and that the best way to simultaneously achieve the best design and the highest quality code is to keep the design and coding activities tightly coupled, so much so that the they are performed by the same people—programmers. Re factoring  a key XP concept, codifies a set of methods for incrementally altering, in a controlled manner, the design embodied in code, further leveraging the programmers role as designer. Two other key XP concepts, "test first design" and automated unit testing, are based on the idea that, not only is the code the design, but the design is not complete unless it can be verified through testing. It is, of course, the programmer’s job to verify the design through unit testing.

Software Design and Programmers2


Many other realities fall somewhere in between the two poles a) of pure, traditional, segmented software engineering, where highly detailed "complete designs" are handed off to programmers, and b) Extreme Programming and micro-size development teams, where programmers are the stars of the show. In the "middle realities" between these poles there are designers, lead programmers, or "architects" who create a design (in isolation or in collaboration with some or all of the programmers), but the design itself is (intentionally or unintentionally) not a complete design. The programmer’s job is to fill in the blanks in the design as she writes the code.
There is one thing that all of the points along this spectrum have in common: even in the "programmers just write the code" software engineering view, all programmers are also software designers. That bears repeating: all programmers are also software designers. In an article for IEEE Software magazine called "Software Engineering Is Not Enough," James A. Whitaker and Steve At kin do an excellent job of skewering the idea that code construction is a rote activity. Imagine that you know nothing about software development. Certainly, you might expect that software engineering texts would be about engineering software. The only design decisions made at the coding level address the small implementation details that enable the procedural design to be coded. The nature of designs is that they abstract many details that must eventually be coded. [Whitaker, 2002, p.108]

Software Design and Programmers1


How important are software design skills to a programmer? Programmers, in the traditional, and perhaps most widespread, view of the software development process, are not themselves seen as designers but rather as people who implement the designs of other people. The real design work is performed by specialized software designers. Designers create the designs and hand them off to programmers, who turn them into code according to the designer’s specifications. In this view, then, the programmer only needs enough design skills to understand the designs given to him. Let’s consider a spectrum of software development "realities." Specialization of function is a key component on these kinds of projects. Analysts specialize in gathering and analyzing requirements, which are handed off to designers who specialize in producing design specifications, which are handed off to programmers who specialize in producing code.
At the opposite end of the spectrum, best represented by the example of Extreme Programming (XP), there are no designers, just programmers, the programmers are responsible for the design of the system. [McBreen, 2003, p. 97] 
Related Posts Plugin for WordPress, Blogger...