Session 4 No silver Bullet

I found Tuesday's class to be really very interesting. There was an open and free flowing discussion about the different papers. The first paper discussed Brooks' (1987) paper "No Silver Bullet: Essence and Accidents of Software Engineering". Using the metaphor of Werewolves, computer programmers/ developers are always hunting for that silver bullet or approach/single development that will cut costs. Brooks argues that this is anathema to the nature of the software problem for a variety of reasons.



At the time Brooks was involved in the IBM SYSTEM/360 (S/360) development and in the article he is hinting towards an object-oriented programming trend which is a programming paradigm that represents concepts as "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs. C++, Java and C# are examples of object-oriented programming languages. This showed developers need to work within an eco-system. There also needs to be constant bootstrapping. Though it was written in the 80s, the majority of the arguments that Brooks highlights and is in favour of still apply today. Standards still apply. Brooks highlights the invisible nature of software and how it is unvisualizable (at the time a lot of software development was done with print out sheets as opposed to using computer monitors) . Compatibility also still apples - IBM worked on backwards as well as forward compatibility.




Complexity and simplicity still applies - there's this essential complexity. You can draw as many process maps as you want but you can't plan it out.



Program Verification - testing programs for bugs still applies. Brooks also argues strongly for rapid prototyping - similar to Facebook's policy today of "move fast and break things". He also advocates for Great Designers to be well paid and for career path recognition.



A question we may well ask is if Brooks was worried about complexity how are we still moving into these areas? One advance was higher level visual programming. We're not actually in this environment Brooks speaks of - he didn't even use monitors, he used print-outs for working.We've moved on to a more complex environment but the underlying sub-strata have stabilised because of standardisation. But the challenges which we face are about the same. But we should realise that aspirationally computer programming is a young discipline in contrast to, say for example, engineering.



The concept of the design and designer was also examined. It was higlighted that the designer often doesn't know how to articulate what he is trying to do.



Racoon's contention is that there is continuity between low level lines of code and big ideas. Have we been able to celebrate the analyst? No.



We asked whether there was any value in what Racoon is pitching in his paper? With the Chaos model: Fractals remind you of an Agile approach - breaking everything into iterations.



As team size and number of nodes grow, complexity also grows exponentially.



Racoon underlines the whole product concept - that everything is intricately connected. When you're writing single line of code you should always consider it's bigger impact. What does Williams add to this?



We can think of Scrum as a wrapping concept.



Below is a photo of Allen enlightening our class:
Full Post