5 ms·

I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can

by sramsay 12y ago

I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people, and in which a certain set of predictable inputs will reliably produce an assured set of outputs. Of course, whether "other areas of engineering" are like this is another question (I suspect that when there's a five billion dollar cost overrun on a bridge, we have our answer about predictable processes). But in the larger sense, I think this is the dream of every geek -- a process, a system that works independently of the people involved. We're going to keep chasing that one down for as long as our business is around. I think Agile changed the way we all work, but it didn't fundamentally change the nature of the endeavor, which is full of guessing, hunches, miscommunication, dropped balls, and overreach, as well as insight, heroism, eleventh-hour refactors, and (above all else) lessons learned through bitter experience.

IanCal 12y ago
> I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people I don't know where you got that idea from, given this vital line in the original manifesto: > Individuals and interactions over processes and tools http://agilemanifesto.org/ http://agilemanifesto.org/ The entire point was to get past the "one size fits none" solutions and just build some stuff.
- dodyg 12y ago
  Would you like some Certifications with that?
- sramsay 12y ago
  A manifesto written after the first burst of agile enthusiasm (and the first major public "failure)." Do you really read, say, the original Extreme Programming book as being in line with that manifesto?
pinaceae 12y ago
that's because there is no engineering yet in software development. it is at the stage of middle ages production, a manufacture in its original sense. client says 'i need a shoe' and developers start from scratch, everytime. it's as if you're tasked with buidling a house and first you design bricks, nails, ... (libraries, frameworks, languages). the fact that shit like i18n to this day is not natively handled by the frameworks itself and does break software in 2014 is amazing. oh you entered a date with saudi locale and their business days do not match ours? oh shucks. outside of large scale public infrastructure projects construction is entirely predictable and safe now. it all starts with education and there is no software engineering one - engineering is all about known entities, process and safety margins. best practices, gathered for hundreds of years. it also explains these massive successes with software right now - it is a very young industry, public utilities do neot exist yet. you can reap massive rewards by offering sewage removal in a better way (facebook).
- steverb 12y ago
  "outside of large scale public infrastructure projects construction is entirely predictable and safe now." My last three home remodels and the recent corporate construction we are in the process of finishing beg to differ with you. Heck, every house flipping/building show on HGTV disagree. The same holds true for mass produced items, especially once they've been deployed. My last pick-up truck was occasionally a nightmare to get parts for since what was on the truck didn't match what the dealer/auto-parts store said should be on there. Figuring out what brake pads to get for the after-market brakes took myself and the old guy behind the counter at autozone an hour and a half of eye-balling and trying stuff. Building anything is hard, and when it comes time to change/fix it it become worse, especially if you need to keep using the item in question during the period that you are "improving" it. You never know what you're going to find once you start poking holes in the walls or pulling parts off.
dragonwriter 12y ago
> I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people, and in which a certain set of predictable inputs will reliably produce an assured set of outputs. No, Agile is exactly the opposite of that: the first value statement of the Agile Manifesto is "Individuals and interactions over processes and tools" The problem is that Agile -- outside of the highly-skilled, highly-motivated, groups that initiated it -- is often a term that the kind of people who are looking for a process that they can trust over people have heard about working without understanding what it means, and so they look for someone to sell them a guide to applying this thing called agile which they imagine to be a canned process, and there are plenty of people willing to cater to that demand and preconception by selling canned processes as "agile" to people expecting canned processes that have some vague awareness of the term "agile" without understanding of its meaning. So many, many venues are implementing some canned process, often defined externally to the organization (the most common, but far from the only, version being Scrum) and valuing strict adherence to its ritual over individuals and their interactions, and believe that by doing so they are "doing Agile" -- and so in the marketplace (though not among people who are more thoughtful and knowledgable) "Agile" has essentially lost all substantive meaning.
- sramsay 12y ago
  A little history, folks. The Agile Manifesto is 2001. Scrum is 1995. Extreme Programming is 1996. ASD is 1997. Easy enough to say that you're valuing "individuals and interactions over processes and tools" after detailing methods and processes that do not set forth this idea at all. Agile (in these earlier formations) was all about processes and tools. Telling me that these formations (in which agile is effectively invented) is "not the true Agile," is like telling someone that the reason they don't like Lisp is because they have not meditated long enough on the Lambda Nature.

by sramsay 12y ago

IanCal 12y ago

> I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people I don't know where you got that idea from, given this vital line in the original manifesto: > Individuals and interactions over processes and tools http://agilemanifesto.org/ http://agilemanifesto.org/ The entire point was to get past the "one size fits none" solutions and just build some stuff.

dodyg 12y ago
Would you like some Certifications with that?
sramsay 12y ago
A manifesto written after the first burst of agile enthusiasm (and the first major public "failure)." Do you really read, say, the original Extreme Programming book as being in line with that manifesto?

pinaceae 12y ago

that's because there is no engineering yet in software development. it is at the stage of middle ages production, a manufacture in its original sense. client says 'i need a shoe' and developers start from scratch, everytime. it's as if you're tasked with buidling a house and first you design bricks, nails, ... (libraries, frameworks, languages). the fact that shit like i18n to this day is not natively handled by the frameworks itself and does break software in 2014 is amazing. oh you entered a date with saudi locale and their business days do not match ours? oh shucks. outside of large scale public infrastructure projects construction is entirely predictable and safe now. it all starts with education and there is no software engineering one - engineering is all about known entities, process and safety margins. best practices, gathered for hundreds of years. it also explains these massive successes with software right now - it is a very young industry, public utilities do neot exist yet. you can reap massive rewards by offering sewage removal in a better way (facebook).

steverb 12y ago
"outside of large scale public infrastructure projects construction is entirely predictable and safe now." My last three home remodels and the recent corporate construction we are in the process of finishing beg to differ with you. Heck, every house flipping/building show on HGTV disagree. The same holds true for mass produced items, especially once they've been deployed. My last pick-up truck was occasionally a nightmare to get parts for since what was on the truck didn't match what the dealer/auto-parts store said should be on there. Figuring out what brake pads to get for the after-market brakes took myself and the old guy behind the counter at autozone an hour and a half of eye-balling and trying stuff. Building anything is hard, and when it comes time to change/fix it it become worse, especially if you need to keep using the item in question during the period that you are "improving" it. You never know what you're going to find once you start poking holes in the walls or pulling parts off.

dragonwriter 12y ago

> I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people, and in which a certain set of predictable inputs will reliably produce an assured set of outputs. No, Agile is exactly the opposite of that: the first value statement of the Agile Manifesto is "Individuals and interactions over processes and tools" The problem is that Agile -- outside of the highly-skilled, highly-motivated, groups that initiated it -- is often a term that the kind of people who are looking for a process that they can trust over people have heard about working without understanding what it means, and so they look for someone to sell them a guide to applying this thing called agile which they imagine to be a canned process, and there are plenty of people willing to cater to that demand and preconception by selling canned processes as "agile" to people expecting canned processes that have some vague awareness of the term "agile" without understanding of its meaning. So many, many venues are implementing some canned process, often defined externally to the organization (the most common, but far from the only, version being Scrum) and valuing strict adherence to its ritual over individuals and their interactions, and believe that by doing so they are "doing Agile" -- and so in the marketplace (though not among people who are more thoughtful and knowledgable) "Agile" has essentially lost all substantive meaning.

sramsay 12y ago
A little history, folks. The Agile Manifesto is 2001. Scrum is 1995. Extreme Programming is 1996. ASD is 1997. Easy enough to say that you're valuing "individuals and interactions over processes and tools" after detailing methods and processes that do not set forth this idea at all. Agile (in these earlier formations) was all about processes and tools. Telling me that these formations (in which agile is effectively invented) is "not the true Agile," is like telling someone that the reason they don't like Lisp is because they have not meditated long enough on the Lambda Nature.