Slashdot Mirror
Agile Software Development with Scrum
What it's all about:
Books that claim to hold the keys to developing software the right way are most often: a) a dime a dozen, b) self-serving vendor drivel, or c) all of the above. While this book is fairly new on the shelf (Copyright October 2001), it has a level of research, professionalism, and effort towards being tool- and language-agnostic that may place it in a fourth category of being: d) none of the above. Agile Software Development with Scrum is a complete picture of the Scrum process from theory to practice in real life examples. The name Scrum was chosen because the process is similar in nature to rugby play where success is built upon being quick, adaptive, and self-organizing. The target audience for the book is "executives, software managers, project leaders, and programmers." While the authors make no assumptions directly, being familiar with Extreme Programming, "classic" waterfall methodology, and having hands-on experience with the chaos of software development is indeed helpful.
The primary theme of the book is simple, but the impact is profound: software development is an empirical rather than a defined process. That's a nice big sweeping claim to make: fortunately, the authors spends a lot of time making sure that you as the reader understand what they mean by the statement and that they're serious about it. Comparisons to other empirical processes are illustrated with examples of changing, complex problems. The authors seek out and provide unique insights from process dynamics experts on the nature of empirical versus defined processes, and cite profound supporting work regarding the limitations of algorithms in complex systems with external inputs (e.g. Wegner's Lemma).
Along with a good dose of theory, there is a generous helping of practice and how-to. Agile Software Development with Scrum covers the basic practices and concepts needed to manage software development in an empirical fashion. The authors do a good job of addressing the classic "but what about..." questions on the spot in a conversational manner and include anecdotes throughout to make specific points and include full process examples towards the end.
What's good about the book?
Scrum is the missing "why" to Extreme Programming's "how." By it's nature, Extreme Programming incorporates all of Scrum's spirit, and vice versa. This book has a foundation of ideas and an explanation of what it takes to seriously improve the state of the practice of software engineering. The order is reasonable, and the depth of information should give any determined individual the ammo they need to make a change in how software is developed in their current job or their next.
What could have been better? There are only three things worth mentioning for improvement, all of which could be easily done. First, there were occasional typographical and formatting errors -- places where indentation, capitalization, or bullets were missing broke the flow. Second, the graphics in more than one section were blocky, low resolution circa 1987. And last, the $30.95 list price was a bit steep for 158 pages. It should be noted that the typographical and graphics issues were the only thing that prevented me from rating this 10 out of 10.
Summary In my opinion, this book has been needed for a long time. The issues and failures of defined processes such as the "classic" waterfall methodology can't be set aside until there is an approach that can justify itself both in theory and in practice to replace it. Extreme Programming has gained much attention, but tends to depend too much on the fact that "it works because it works." Scrum gives you a way to fix your development efforts without as much culture shock or risk. It's worth considering implementing before your competition does.
You can purchase Agile Software Development with Scrum from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Scrum is a way for everyone to feel good about their job
might be worth a purchase, but still not completely sold. self-organizing is nice when engineers on the team understand the reality that organizing with other team members is good thing. It still doesn't help when one member of a team doesn't listen to anyone and ends up rewriting their code 5-6 times.
...While this book is fairly new on the shelf (Copyright October 2001)...
Since when is a year and a half "fairly new"? This makes me wonder if both this book in particular and extreme programming in general are really the Nirvana they appear to be? Is lack of promotion for or lack of substance with extreme programming the reason the Big Guns like IBM and Sun haven't promoted Extreme Programming Consulting services, or have they simply not found a way to co-opt the market yet?
The twist this time, is that he posted the dupe an HOUR AND A HALF after the first one. Not a week. Not a day. 1.5 hours. There was only ONE story between them.
Amost every single post in the discussion attached to CmdrTaco's article says "OMG DUPE".
Of course, he didn't bother reading this (nor the other stories on the front page). Once he woke up and discovered that his idiocy was laid bare, he had the nerve to suggest that the readers should have emailed him:
Listen up, shithead. YOU should be proofreading and checking up on your posted stories, NOT THE READERS. Some readers ACTUALLY PAY YOU, so the least you could do is not insult them by posting dupes and implying they should do your checking for you.
What a fucking worthless prick.
It's not a secret, why business-driven software development so often turns to be a such a mess. The demanding part (management, customers) is just plain stupid. No, sorry, bone-headed whould be a better term.
"We don't know what we're doing"...
"So we'll fake it"...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Sounds like an interesting book. I'm always on the lookout for good books on program design methodologies and software development strategies. I've come across a few for OOAD and a using the Rational Unified Process that have caught my attention within the past three years (the titles of the two books escape me at the moment). Although neither are as heavily referenced as some of my programming books, they still had a good mind set for development life cycles and methodologies that I've used in projects that I'm working on, both large and small. Then I've read some total dogs that really sucked, such as System Analysis and Design Methods from McGraw-Hill. Although it had a few (and I mean very few) good points, most of the book was regurgitation of the garbage that they summarize in the first few chapters. The only thing that I'd give a plus is the follow along of a new analyst in a developing system and the interactions he has with the development team (which after about 3/4 of the book, I ended up just reading those, after all, it was kind of nostalgic to remember what it was like to be so eager to jump into a project that you'd spout out technologies and algorithms when you meet a customer for the first time, only to have them look at you real funny and have no clue what your talking about). Id be interested to hear what books the rest of the Slashdot community would recommend as real jewels on this subject.
I can't help but think all this is just one giant mind fuck. The IT industry is such a volatile industry that seems to love to be lead around by the nose and is greatly influenced by the flavour of the month.
Why not try to take a look at some of the long time methods used by engineering industries to see how they go about designing bridges and cars and stuff like? Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?
All the best,
--Bob
Seems to me that "end up as a mess" describes software efforts in general, no matter what drives them.
Build stuff. Stuff that walks, stuff that rolls, whatever.
They have discovered that the Tao is the heart of all programming.
Hark, the master speaks:
Learning what Scrum is and how to practice it is not all that profound. However, sitting back and realizing why Scrum works and how it addresses the fundamental flaws of the last 20 years of software engineering is.
Once you obtain that realization, you will have truly mastered the Tao.
I glanced at this book before, and I found it totally useless. The few ideas presented are already well-known facts about software engineering, heavily adorned with buzzwords like extreme programming and agile software. I did not see a single idea that was not present in Fred Brooks' "The Mythical Man-Month", that was written back in the 70s. Do not waste your time with this: I'd much rather read a classic, timeless work on project management and its challenges that this scum. If you want to look at contemporary, more applied works, I recommend Steve McConnell's "Rapid Development" and "Code Complete".
I've worked with XP on 2 projects and more normal "MSF"-like approaches for about 7 projects. (The remaining ones were kind of unmanaged to begin with, which is the pits)
Anyways, XP doesn't work. Proponents like to say that XP is high throughput, but I just don't see it. At my last job (where XP was employed) programmers had to put in long hours, despite this being against XP tenet. This resulted from abbreviated design cycles and hit-and-run feature development.
We like to talk about agility and mentally substitute quick hack jobs as a way of limiting cost overrun when features change midcourse (which they often do). What XP people don't tell you is that XP encourages these features to be hacked in (simplest thing possible, remember?) without regard for how it might be later removed with little effort.
In other projects where features were designed and implemented with a good degree of modularity, that feature was canned or changed, yet we were able to extricate it with little effort - simply by #defining it out or by not shipping the modular DLL it resides in. In comparable XP-driven projects, I've been told "No, modularizing it is not a requirement. Do the simplest thing - add whatever you need to the existing classes and just do it."
In XP, implementation is cheap up to a certain point where suddenly refactoring becomes imperative. Refactoring is then a very painful process given a very short iteration cycle. You won't find an XP shop that will encourage modularity over implementation time. But, like anything, the biggest gains come from pacing and managing, not from writing as much code as possible in a short amount of time.
Ok, so now you say that pair programming compensates for the short design cycles. Get real - no one really does this because this, too, does not work. Most programmers are like any other people - they can be tempermental, stubborn, selfish, and proud. The worst part is, the younger and more inexperienced the engineer, the less willing he is to accept other points of view. Try working with that. You can't.
Where XP excells is late stage bug fixing, where hit-and-run is definitely the right strategy.
In my 10 years software development experience, I've come to the conclusion that people are by far the most significant factor in the success or otherwise of a project.
:)
In fact, I believe that people are so significant that they make the use or otherwise of any particular "methodology" an irrelevant ingredient in determining the outcome of a project.
Good coders will produce good results with or without methodology.
Average / below average coders will produce average or below average results with or without methodology.
Trouble is, it is impossible to test this theory experimentally; you just have to believe it
I think.
Hi,
Why can't software be more like [real engineering field]? Nobody messes around with [extreme programming|OOP|empiricism] in [real engineering field]! I mean, how would it be if [bridges|planes|hospital equipment] were designed like software is? Books like this just make me realize that [software engineering is not real engineering|my branch of engineering is harder and therefore better|OOP is all a myth and everything should be in FORTRAN].
Yours truly,
[crusty old engineer|enthusiastic young engineering student|idiot]
optional: P.S. the term software 'engineering' is a misnomer
Whence? Hence. Whither? Thither.
Is a piece by Mountain Goat Software, they explain things with pictures, much better for us simpletons.
1) It's a systems thing, so I don't really need to know the details, and
2) I'm too busy to get involved with this effort, even if it means a total redesign of my job.
arrrrggggghhhh....
Stop by my site where I write about ERP systems & more
A quick search on google reveals their past work:
"Ken Schwaber is a Senior Consultant with Cutter Consortium's Agile Project Management Practice and is an experienced software developer, product manager, and industry consultant. He has been in the industry for more than 30 years, starting as a programmer and, by 1984, managing IT for one of Wang's divisions. In 1985, Mr. Schwaber founded Advanced Development Methods (ADM), a company dedicated to improving the software development practice. He initiated the process management product revolution of the early 1990s, when methodologies were automated and put to practical use on ADM's Mate process manager...."
So basically a software development manager for failed Wang that went on to make a company that tells other people how to run projects.
and Mike Beedle:
http://www.mikebeedle.org/
Runs two businesses, started out as a Lasers expert in 93, then in 94 switched to writing books on programming, judging by his papers.
Guys, if you post PR puff like this on Slashdot don't you think people will check if you know what you're talking about?
"The Mythical Man Month" is old, and isn't yet another methodology that washes whiter than white. But it's small, easy to read, and needs reading by most people involved with managing software development. Then they won't believe that getting more developers will lead to faster development.
Or maybe I'm making a mistake - maybe all of you have read this already...
[Fred Brooks, ISBN for my edition = 0-201-83595-9, details on amazon]
"we demand rigidly defined areas of doubt and uncertainty!"
We've already known why software development is screwed up, and known that for 25 years. Any new book that can't articulate what the known problems are and exactly how the new technique addresses some of those problems is a complete waste of time. And any reviewer who can't convey in his review whether the book is addressing some of these issues is completely wasting our time.
The whole Scrum thing was a major change of pace for the company I used to work for. They had just "re-engineered" the company, and extreme programming was the next "in" thing for executives to do, so they hired on a new VP (nothing gets done in a company like this without a new VP to manage it) and that VP brought in Scwaber. Apparently, the guy was a real jerk, and there was major friction between him and the rest of the company. One person I know who actually worked with him called him 'a cancer' and claimed he connived to get people fired, including one manager whose job he coveted. From what I was told, Schwaber himself actually got fired over that.
Scrums worked out OK, overall. Since I was not a developer, the daily meetings actually were good for me, because that's when small issues that I needed to know about usually got hashed out. Not being a developer, I can't say much beyond the daily meetings on how scrum worked out.
I transition out of development about 6 months after scrum was introduced. There were major morale issues at the company, and about a year and a half later I finally left to a small startup. It's hard to untangle how scrums worked out in the environment where there were many other issues negatively affecting the company. Lots of stupid decisions, lots of idiot executives. The group I was in just before leaving the company was laid off entirely a month later. Then they freaked out and rehired several people, with back pay and huge pay increases, because they realized after the fact they couldn't get along without them. The company has survived, and its stock has actually gone up in the past year.
In most cases, it is better to not hire bodies. In all the cases I've seen first hand, it results it delays and problems. Not only are the good programmers bogged down with stupid questions, but they end up spending time fixing other's code. The end result is the same programmer is less productive. There really should be a book that teaches programmers how to negotiate with management and how to work with HR. I've had to learn that the hard way.
i thought it was the process of looking at your coded scum and drowning the rising depression in rum, which is a special technique in gonzo-programming... ;-)
the computer is online
i am not at it
what a waste of ressources
You know what, it was inappropriate of me to spread rumors about that guy. Please do me a favor and mod the above down...
After 3 years in full development, all I can say is that the most important part is defining good requirements; which means that the real needs have been understood well. So, the more time is spent in planning and discovering requirements, the better course the project has.
and they don't call it scrum, it's called overlord-peasants. The overlord picks what to do , and the peasants do it. The trouble with scrum is that it's only as good as the overlord / manager can be, because if they are adding features that 1) take too long to implement, or 2) don't really help in the long run, then the whole process is wasted. You turn out crap really, really fast instead of turning out crap slowly... fast or slow, it's still crap.
stuff |
I wonder how far this will fly with nazi project managers. They are fairly attached to their ass-backward "methodologies", you know.
Seriously, for the record, I agree with the statement above. But this type of thing simply does not work in most IT shops. I have no problem with some sort of control over the software development process (that is, I'm not saying PMs and PDs are completely worthless) but telling them something like this will probably be useless. They don't think of software developers as artists or craftsmen, but rather as "resources" that need to be managed, cajoled and pushed to meet deadlines. Nothing more, nothing less.
Sad, but true.
Every few weeks someone posts a book here about some new "methodology" that will save the world of Software Engineering. Please write this down and stick this on your forehead. Then have your pair programmer read it to you once in a while:
1. Programmers are not engineers
2. Programming is a human-centric activity
3. There are no "silver bullets"
4. Agile methods are useful only to the extent that they remind us of everything Fred Brooks already said.
Read here.
Where did I see this ad for software for the fragile business? ID software? Quake3 arena?!! What's agile? when you can frag-ile them more rapidly than your peers. It's agile to sell to them fragile-minded business people a package, software with a membership fee that will be a drain on their resources. It's software for the fragile business so that competitors with the agile OS can slam dunk em off the market with lower prices... agile software development.. what a buzzword! Maybe its GOOD but why use a tainted term?
Of those to whom much is given, much is required.
Describes how to generate useless bloatware using techniques derived from the favoured tactics of the front row - futile, irritating and devoid of any entertainment value.
oh brave new world, that has such people in it!
it's just that they never listen.
You're supposed to write the manual first, with the users, flesh out the help screens, write psuedo code, then code. Coding is 20% of billing.
No manager is going to tolerate that, s/he wants to see working code before the first payment is made, and lots of it. After the users complain that nobody asked them, you go back and modify it. You never get around to doing the manual, and help consists of your support contract soothing confused users.
This is why software sucks. Ask the lusers who are stuck with Results/Plus, Paradigm, or any other vertical market app.
First "Extreme Programming", now "Scrum". Yuck.
Healthcare article at Kuro5hin
That's just long enough to be considered smart by management and stupid by your co-workers. Unless your co-workers have all of 2 years experience. In that case you know it all and you're a god:)
quick, adaptive, and self-organizing?? Have the authors ever met rugby forwards?
For those of you in the Seattle area Ken Schwaber will be presenting a talk entitled
"Agile Processes and the Scrum Methodology" at the meeting of the Seattle Java Users Group at 7 PM tonight.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
Check the newsgroup. He can't make it because of the snow storms on the east coast. He's stuck in Boston at the moment...
(subject says it all)
Liberty uber alles.
My last company's advertised methodology was SCRUM. We told all of our customers we used it, and management even convinced themselves that we were using it.
The funniest thing is that SCRUM isn't necessarily a bad model, it's the people who think that it's a quick fix to their process that is the problem.
These KISS methodologies seem pretty hard to screw up, but when you have a team constructed of the wrong people (micromanagers, pigheads, and big-methodology freaks), it's a recipe for failure. Because of the team composition (and team member apathy for that matter), our sprints rarely (if ever) yielded the expected or desired results.
The thing I couldn't stand the most about SCRUM, however, was the silly terminology lifted from rugby. Sports metaphors in a field dominated by nerds? Ugh.
Oh wise programmer, I see that you also have been reading "The Tao of Programming" by Geofrrey James (ISBN 0-931137-07-1). Sharing wisdom and giving credit is the open source way to true enlightenment.
"A program should be light and agile, its subroutines connected like a string of perls."
We could scrum, but that just wouldn't have the same effect as:
:p
Software (yes it is!)
Creation of some bugs
Realization of the fact we have bugs
Objectification of the bugs into modular and reusable parts
Timing of when to unleash bugs
User requirements: They had better require bugs!
Many Iterations to turn bugs into Features!! (MS only needs one iteration to do this)
Or we can just call it SCROTUM. For example, insted of saying: let's SCRUM, you could say: let's scratch out that SCROTUM problem.
This poorly worded acronym brought to you by the letters X and P.
AntiFA: An abbreviation for Anti First Amendment.
google for more info
Slashdot Journal on Monopoly News
After reviewing the first 73 comments on this book review, there are some important background pieces of information missing.
SCRUM was invented by technical people for technical people by a Smalltalk team in 1993. The inventors were well steeped in Brooks Mythical Man Month. The challenge was to get mere mortals to function as well as Brooks Surgical Team, which IBM had shown was the highest productivity approach to software development. The solution came from the Japanese auto industry where they first applied the SCRUM term to new product development. Critics should read:
Takeuchi, Hirotaka and Nonaka, Ikujiro. 1986. The new new product development game. Harvard Business Review 64:1:137-146 (Jan/Feb), reprint no. 86116.
SCRUM is designed to eliminate all project management meetings and replace them with one technical meeting a day about 15 minutes long. It should be led by a technical leader, i.e. someone who does real coding. All decisions are made in the SCRUM.
SCRUM is designed to get management out of the way and to assign them tasks they are responsible to fix, i.e. get stuff out of the way that is blocking team progress. If they can't do that, the SCRUM should replace the managers.
SCRUM is designed to completely eliminate project leaders. Project planning and reporting including complete charts and graphs that will satisfy senior management is designed to be done in less than 10 minutes a day. Development input for project status should be restricted to less than 60 seconds a day. GANTT charts are verboten.
If a SCRUM doesn't do the above, it is not a good SCRUM. Management must give up some control in return for getting a better product faster. Anyone who has seen SCRUM really work will never go back.
Jeff Sutherland http://jeffsutherland.com/scrum
You may already know this, but when you said, "... Say you know a select should return x number of values..." it reminded me this bit of wisdom:
If you have mock database connections, don't let the name fool you. They're not database connections, and you shouldn't implement any kind of whole 'layer' in a mock database connection.
Which means, if you can hand your code that is under test a mock connection, don't have one "mock connection" for the whole system. Make a "mockMyThingConnection" that (if it can) stores off the requests in order, and returns a predetermined set of results. Then check the requests to be sure they're what you expected.
The simplest case of this is where you have something that makes one simple query, like looking up a country. Your unit test can make a simple mockConnection (heck, it could be anonymous , even) that will check that the request it gets fits some sanity values (asks for the country table and includes the code passed in, for example) and then returns the result you expect the real data layer to give you.
This mockCountryConnection is *only* for this test case, and is trivial to write.
You're right that you won't catch any problems with the data layer for this kind of unit test, but then again, you're not testing the data layer. Presumably, you have other unit tests for the data layer, then integration tests (perhaps monkey-based*) for the interaction between them.
I tell myself every day, "MockObjects do not have to do anything resembling the full contract of the objects they replace".
-Zipwow
* Monkey-Based Integration Tests: This is our current approach where I work. It involves one or more non-automated semi-intelligent button-pushers who follow a rigorous training program before going bannanas on the application.
Unfortunately, we're non-optimal in our implementation of this because we have extra-intelligent humanoids doing the heavily scripted (but not automated) button-pushing. This is non-optimal because their talents of interface evaluation, and non-obvious error detection aren't being fully utilized.
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
My intent with this review was to give a general overview and introduction that had a wide apeal. Perhaps I went a bit too wide:) Either way, it has given me an appreciation for the challenge of attempting to write a summary of any involved technical topic.
If I subject the public in the future, I may have to stick with Kuro5hin over slashdot so I can get more editorial feedback and provide a clearer picture.
*** Sigs are a stupid waste of bandwidth.
unlike eXtreme Programming, which is mainly about coding.
Scrum is all about managing the project, and in a way which matches the reality I perceive better than "traditional" models.
I've read the book in question, and I believe in Agile methods. One of the comments above says "methodologies are nowhere near as important as people" - check out the Agile Manifesto; line 1 says "we value individuals and interactions over processes and tools". Ken Schwaber (and Jeff Sutherland, who posted a reply here) are co-signatories.
The big problem I have found with Agile methods is that often the senior management team is unwilling to relinquish the impression of control over their projects. They insist on knowing everything up front - time, scope, budget - and even if they understand the empirical nature of software projects, that sense of control is very hard to give up.
I have found many of the "Top-down" implementations of Agile processes to be buzzword driven - the last thing you need to do Scrum is a new VP; the Scrum is intended to make the VP redundant ! I'm not surprised many people have had bad experiences with XP - the 12 practices are finely balanced, and distorting that balance (e.g. by over-emphasizing "the simplest thing that could possibly work") is a great way to ruin a project. Of course, I'm inclined to believe those organisations will struggle with any methodology; one thing Agile methodologies seem to do is draw out organisational weaknesses.
I'm working on a project right now where we have a very agressive schedule; we are pretty sure we can code the thing, but because our average corporate decision takes longer to reach than the project's timeline, we're hitting some rough spells. The cause is the decision making process; the effect is an unhappy project. In a "traditional" project, with analysts and project managers etc. and a sizeable up-front analysis phase, our corporate weakness would be less obvious; because we're saying "decide today, we'll have working code by the end of the week", our inability to decide is highlighted.
I'd recommend Ken's book; it's worth reading, and even if you don't agree with all he has to say, you might learn something.
It's all very well in practice, but it will never work in theory.
Agile methods, including scrum are really a developers best friend. A core part of scrum, is the daily scrum. A 15 minute meeting in the morning that asks 3 questions:
It puts the focus on the bottom line, which is productive development. It's really so simple that you shouldn't even need a book to understand this. But, people generally make things more complicated than they have to be.
The book does make for interesting reading. The formatting and graphics do seem from 1970 though. I suspect that the authors used agile techniques to get the book out the door really quick.
What's a sig?
about Scrum tomorrow (wednesday)
What the...? The raison d'etre of nearly all commercial software, barring games, is to meet some business need. Whether it is for external customers (in the case of software houses) or internal business users (for in-house IT depts.), we develop tools to solve business problems. All too often, software development results in something some backroom cowboy reckons is really 7337, but fails to adequately meet the actual business needs of the user, precisely because the development was not business driven. Sure, as developers, we facilitate and guide, and provide professional advice on, development of software, but come on!
How the hell is software supposed to solve business problems if it's driven by some haxor's wet dream rather than business? What a bizarre world view, even for an 'engineer'.
In order:
1) Have a good manager (the more the better)
2) Have a good programmer (the more the better)
3) Have a process congruent to your goal.
Processes will not eliminate the need for managerial or technical competence.
They do, however, help:
- communicating with the team
- communicating with the customer
- keep an eye on quality.
And the whole point of this "communicating" is to:
- gather requirements
- clarify requirements
- prioritize requirements
- make people realize ASAP the requirements have changed
- figure out how the heck we can encode these requirements in software
The whole point of agile methods like XP or SCRUM is to support projects where requirements aren't clear, their priorities aren't clear or change, and requirements themselves change. Which is like most in-house business environments. It might (or might not) be appropriate to product development.
Cheers
-Stu
Complete in agreement.
I'm doing research in the building industry and many of the things you mention are valid in the building industry too. In a different wording:
Allmost everything is a one-off project. We ain't building 10000 volkswagens of about the same type. THEN you can do some "traditional" engineering and some heavy process optimisations. Basically the building industry builds prototypes only (apart from soviet housing blocks).
Changing requirements. Yes. The architect changes his mind. The customer changes his mind. The constructor has to do it. Faults creep into the design, the constructor has to compensate for it.
Perhaps an extra analogy:
BAD BAD professional relationship between customer and contractor. The customer wants the cheepest ride possible. The contractor has to accept it. But the customer unvariably made errors in his specification. The contractor is quite happy to do a bit more work to correct that, but he attaches a hefty price tag to it.
Both the construction and the software industry have their big problems. Some can be cured by better processes, some by a culture change, some by better information. But probably not all.
Well, that's where we engineers are for, isn't it? Solving nice problems!
Reinout
Reinout van Rees
mod parent up please.
Dont we have enough bullshit as is? When are we going to realize that it is all about having good software engineers who have a passion for development as opposed to a stupid methodology?
and I aint no cock sucker. Good 'ol fashioned software development has served me very well. all these bullshit methodologies is all talk no shit. Every methodology, along with a bunch of bullshit, evntually says its about having good engineers. Hell, with good engineers you dont need a methodology, they are good engineers because they know what works through hard earned experience. Methodologies are for inexperienced engineers. Why everybody is looking for this magic bullet is beyond me. Look for good engineers that despices methodlogies... those are the ones that will make a project succeed, not methodolgy idiots that wants to hide behind a process.
IT monkeys who havent done any Computer Science is heavily in need of methodologies to hide behind processes, so they can cover up their incompetancies by following a process. I've also found this to be true for managers as well that have gotten out of their engineering roots into managing people. In the process of looking for advancement, these managers have lost their true passion of solving technical problems, and have come to be those they despice; paper pushers, managers that have to kiss ass for their next advancemet, etc. Its these kinds of people that seek methodologies to help them complete a project, and sadly they have forgotten what really matters; the engineers that solve the problems. So, they come up with these methodologies when they hear some one at GM or Ford used a methodology and completed a project. Whe the project finally succeds, because of the hard work by the team of engineers, the insane manager writes up a post on slashdot about how good the methodology is, instead of giving credit to his team that really made the difference. The real truth is that companies like GM and Ford have poured so much money into their projects that they really cannot fail any more.
By contrast, real Software Engineers, would like to think for themselves and excell in their projects because they have a passion for solving real problems, and find themselves hindered by monkey managers who push processes over intelligence. If this is not the truth, open source projects like Linux would not succeed. they dont dictate a process over people, infact they reward people over a process; self fullfilement fo doing something right.
Another mindfuck session saved by the snow.