[News]

News: Welcome to The Oktave Forum.

[sids]

sids

sids

Visit sids's website.

Show sids's last posts.

Show general stats for sids.

• 
• God
• Administrator
• Full Member
• Karma: 65535
• Posts: 132

http://www.technicat.com/writing/process.html

"The patient died, but the operation was a success."

Philip Chu wrote this interesting essay debunking the many widely purported myths about Agile Development being the magic bullet for Software Engineering. Makes an interesting read for anyone who is involved in software development.

[sri]

sri

sri

Show sri's last posts.

Show general stats for sri.

• 
• Administrator
• Sr. Member
• Karma: 7
• Posts: 264

Software engineering is increasingly looking like a huge mud slinging match with everyone calling everyone else stupid or mediocre.

What I really miss is someone trying to understand the nature of software. Software engineering is fundamentally about manipulating information unlike traditional engineering, which is based on manipulating the physical world. I've been thinking quite a bit about the fundamental nature of information and I have reasons to believe that the underpinnings of information are quite different or more fundamental than the foundations of physics.

I remember once in a talk on protein folding by a professor, one of our students had remarked that "ultimately everything is physics." If we understand principles of physics, in theory, we should be able to understand even biological phenomena like protein folding.

It set me thinking further on, and I can assert now that it is not really true. Which law of physics, for example, can we use to prove that there are an infinite number of prime numbers?

I think mathematical principles cannot be explained by physics (but perhaps the converse is possible).

And software engineering is based on foundations rooted in mathematics, not physics. And we hardly understand the foundations of mathematics to the extent we understand the foundations of physics.

Agile, non-agile; process, ad hoc are all okay. But an understanding of what exactly constitutes the challenge in software engineering is what is copiously missing. No, not even Mythical Man-month explains it well enough.

[Siddhi]

Siddhi

Siddhi

Show Siddhi's last posts.

Show general stats for Siddhi.

• 
• Newbie
• Karma: 1
• Posts: 2

Well there are various approaches to building software, which affects the perception on the "right" way of building software.

• The engineering perspective: Building software is like building a bridge -> Emphasis on requirements & design documentation
• The factory perspective: Building software is like manufacturing -> Emphasis on process
• The mathematical perspective: Building software in a way that every component is provably correct -> Emphasis on specifications
• The art perspective: Building software is a creative activity -> Emphasis on individual coding
• The craft perspective: Building software is about creating something -> Emphasis on coding & testing

The traditional view has been the engineering perspective. Agile tends more towards the craft notion. Also there is the perspective of coding as an individual activity or as a group activity. Popular notion is that it is an individual activity, with the image of the lone hacker coding away into the night. IBM commissioned a study in *1978* where they found only about 30% is individual, and 70% of coding is done as a group (2 or more people). Traditional process view has been of coding as an individual, agile processed tend to favour the group view.

I like Alistair Cockburn's view of software development as a cooperative game - http://alistair.cockburn.us/index.php/Software_development_as_a_cooperative_game

[sids]

sids

sids

Visit sids's website.

Show sids's last posts.

Show general stats for sids.

• 
• God
• Administrator
• Full Member
• Karma: 65535
• Posts: 132

Well there are various approaches to building software, which affects the perception on the "right" way of building software.

• The engineering perspective: Building software is like building a bridge -> Emphasis on requirements & design documentation
• The factory perspective: Building software is like manufacturing -> Emphasis on process
• The mathematical perspective: Building software in a way that every component is provably correct -> Emphasis on specifications
• The art perspective: Building software is a creative activity -> Emphasis on individual coding
• The craft perspective: Building software is about creating something -> Emphasis on coding & testing

The traditional view has been the engineering perspective. Agile tends more towards the craft notion. Also there is the perspective of coding as an individual activity or as a group activity. Popular notion is that it is an individual activity, with the image of the lone hacker coding away into the night. IBM commissioned a study in *1978* where they found only about 30% is individual, and 70% of coding is done as a group (2 or more people). Traditional process view has been of coding as an individual, agile processed tend to favour the group view.

I like Alistair Cockburn's view of software development as a cooperative game - http://alistair.cockburn.us/index.php/Software_development_as_a_cooperative_game

That's very well put, thanks!

Of course, in reality, Software Engineering is probably all of the above (and more) to varying extents. That might also be why treating it as any one of them, while solving some problems, introduces others. It is nevertheless important to realize that there is "No Silver Bullet." There is a very well known paper titled as much, a must-read for all Software Engineers: http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf

A small clarification, just in case: I'm personally not against Agile methodologies per se, but I'm definitely against any methodology/technology being tauted as the silver bullet that is going to solve all the worlds problems (let's get real, we're engineers, not beauty queen contestants .)