Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Practices of an Agile Developer

samzenpus posted more than 7 years ago | from the stretch-first dept.

Book Reviews 172

Cory Foy writes ""Whatever you do, don't touch that module of code. The guy who wrote it is no longer here, and no one knows how it works." In Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt put that quote as an example of something we are all afraid to hear, but probably have in our careers. They then go on to list a collection of practices which can keep you from hearing, or worse, saying that phrase. How do they do?" Read the rest of Cory's review for the answer.

I was excited when I received this book. Having gotten the chance to meet and talk with both Venkat and Andy, I knew they were passionate about getting developers to understand how to deliver value to the customers. Both are proponents of Agile development in one form or another (XP, Scrum, Crystal etc). But rather than try to sell you on one of the methodologies, they laid out seven goals: Beginning Agility, Feeding Agility, Delivering What Users Want, Agile Feedback, Agile Coding, Agile Debugging, and Agile Collaboration

In the first, Beginning Agility, they lay out the basics of becoming an Agile developer. Things like Working for Outcome (in other words, don't blame people for bugs, find out how to fix them and fix the process that caused them) and Criticize Ideas, Not People. Or avoiding the pitfalls of making quick hacks without trying to understand why the hack was necessary (Quick Fixes Become Quicksand). They finish up the chapter with a key word I personally feel is absolutely necessary in software development — courage. They put this in the context of Damn the Torpedoes, Go Ahead. In other words, if the code you are working on is stinky, and you'd like to throw it away, don't be afraid to bring that up. Or if code you are in the middle of building suddenly becomes the wrong direction, stand up and explain that (being sure that in both circumstances you have alternatives for getting it on the right track).

The second chapter, Feeding Agility, discusses ways to keep the flow going while being Agile. Things like Keeping Up With Change remind us to keep our skills sharp and honed. Invest in your Team shows that if you don't bother to spread your knowledge, they'll be unlikely to spread theirs with you, and if the goal is to deliver the best product we can to our customers, that just seems counterintuitive. Of course, it is just as important to Know When to Unlearn. Sure, that ASP solution you've had for 10 years works Ok, but that shouldn't stop you from exploring other new technologies. When you don't understand something, you should Question Until You Understand and finally Feel the Rhythm that Agile brings.

Now comes the contentious part. If our goal really is to deliver the most value to our customers that we can, then it makes sense that they should be able to drive the process. In Delivering What Users Want we hit some turbulent waters with topics like Let Customers Make Decisions, Let Design Guide, Not Dictate, and Fixed Prices are Broken Promises. But, to me, this is one of the most important chapters, and they do a good job of explaining how to accomplish all that with things like Getting Frequent Feedback, Automating Deployment Early, Integrate Early, Integrate Often, and Keep It Releasable. In addition, the use of Short Iterations and Releasing in Increments helps keep the flow going and communication with the customer high.

In order to keep up with the high level of customer communication (and confidence), you are going to need assurances your system is working properly. In Agile Feedback, Andy and Venkat discusses ways to get feedback in ways other than from your customer. At this point, if you've been on traditional projects, you are probably thinking the only way you could do this is with Angels on Your Shoulders, which they explain how to get with a safety net of automated unit tests. To really get a good sense of how to keep the design clean, they use techniques such as Use It Before You Build It and running it on a build machine other than your own since Different Makes a Difference. Finally, to understand how you are really doing, you have to Measure Real Progress which you can do through Automating Acceptance Testing (using something like FitNesse). Finally, you have to Listen To your Users. Similar to the way that you should treat compiler warnings as errors, customer complaints are a sign that something is wrong — especially if it is a high number of customers experiencing the problem.

Now that you are Agile with your customer, the authors begin to target the specific code you are writing in Agile Coding. This is a list of some key tenants of good development, such as Programming Intently and Expressively and Communicating in Code (and not chiefly through comments, either!). But there are some practices that are harder, but just as important like Keep It Simple, Actively Evaluate Trade-Offs and Code in Increments.

No matter how hard we try, though, defects still creep in. Or, we don't get the chance to work with pretty Greenfield code, but are dropped in the middle of a big ball of mud. How do we get out? In Agile Debugging, Andy and Venkat cover some great techniques including Warnings Are Really Errors (mentioned above), Report All Exceptions, and Provide Useful Error Messages.

But one of the techniques was something I had not done before, and I thought was excellent — a Solutions Log (also called a Daylog). In other words, when you come across a problem, document it, and when you solve it, document it. No doubt, you'll come across that problem again, and when you do you'll be glad to be able to go back and figure out how you solved it — especially if you don't have the code you fixed it in the first time. (I have a tendency to record anything I come across that I know I will see again on my blog, and I tell you that typing a question into Google and the first result being your own website is the perfect way to make you feel like a total moron).

The final section, Agile Collaboration, is my idea of a dream team. First, you have to Schedule Regular Face Time to talk about what is going on in the project — especially if you all are working on the same code base! You have to be able to practice Collective Code Ownership (meaning anyone should have the knowledge to change another part of the system), and also means that Architects Should Write Code. To help grow the team, you can Be A Mentor, but to do it effectively you have to Allow People To Figure It Out. Some final practices are around respecting your team by Sharing Code Only When It's Ready, being available to Review Code, and Keeping Others Informed about what you've learned.

I enjoyed the layout of the chapters too. Each one starts with a "devil" which often times was saying something I've heard on one team or another. It finishes with an "angel", and a section of what it feels like to be doing the practice. Andy and Venkat also pepper the text with plenty of real world situations that reinforce just how bad software development can be.

In summary, if you want to be a better developer, but think Agile is a misused buzz word, go to your local bookstore, put a small piece of masking tape over the word "Agile" in the title, and buy this book. You won't regret it.


You can purchase Practices of an Agile Developer from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

172 comments

Agile? (0)

Anonymous Coward | more than 7 years ago | (#17039038)

I, like most software engineers I know, are most assuredly not agile. Lumbering, bloated, super-sized or fat perhaps, but not agile.

Well I am a developer and I am very agile (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17039040)

AND I LOVE IT WHEN COCK IS SLAMMING UP IN MY ASSHOLE

Sincerely,

Rob Malda
Slashdot Editor in Chief and Agile Developer

# ply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might b# ply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might b

# ply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might b

Update on the link (3, Informative)

Anonymous Coward | more than 7 years ago | (#17039062)

The review here inexplicably links to B & N, who offer the book at a fairly high price compared to Amazon [amazon.com] .

Re:Update on the link (1)

Diss Champ (934796) | more than 7 years ago | (#17039370)

Slashdot always links to B they get money that way. It's good check around whenever looking for a book- they're just telling you one place that has it, not where you have to get it.

IT'S TACO'S PETTY CASH FUND FOR TWINK WHORES (1)

CmdrTaco (troll) (578383) | more than 7 years ago | (#17039664)

Bareback ain't cheap, you know and Amazon kickbacks just don't cover it.

Re:Update on the link (5, Informative)

MyNymWasTaken (879908) | more than 7 years ago | (#17039608)

Say hello to my little friend.

Price Comparison Table [addall.com]

Buy.com has it for $2 cheaper than Amazon.

Code modules start with great intentions (5, Insightful)

LiquidCoooled (634315) | more than 7 years ago | (#17039098)

Then real life gets in the way and your first gen mock up becomes live code (after the boss sees it - "but its working, why do you need to rewrite it...") and you curse yourself every time you open that code.
We have all got our monsters.

Re:Code modules start with great intentions (2, Interesting)

turbidostato (878842) | more than 7 years ago | (#17039276)

"Then real life gets in the way and your first gen mock up becomes live code (after the boss sees it - "but its working, why do you need to rewrite it...") and you curse yourself every time you open that code."

Who wrote the code? You!

You can be sure *you* are the one to blame, not your boss.

If you are working on a mockup GUI, be sure no functionallity is within the demo.

If you are working on a mockup funtional unit, be sure is terrifying ugly so no PHB will think it's ready.

When you are programming, as a general matter, first comes the comments, second the bound tests, third the functionality, and last (if needed) the API or the interface.

Not only you won't have to pass through the "compile? it's production, then", but your code quality will enhance almost without you noting.

Re:Code modules start with great intentions (1)

LiquidCoooled (634315) | more than 7 years ago | (#17039408)

I don't even go near a computer whilst developing - pencil and paper is best.

If its something I am testing and playing with in a side project I get time to craft it into a final piece and this works nicely most of the time.
The code I am talking about is just a tiny fraction of the entire system and I've cursed myself from the moment I opened my big gob (it was just one alternative export routine) and gave a quick demo (I was expecting dev time to move it into the real project properly).

Re:Code modules start with great intentions (4, Funny)

Dunbal (464142) | more than 7 years ago | (#17039596)

I don't even go near a computer whilst developing - pencil and paper is best.

      (pulls up another pillow and offers a seat under the tree, on a hill overlooking the valley)

      (rolls up a "special cigarette")

      Man, I'm telling you. Paper and shit is all good. But, you've got to get real mellow like, and think about the problem (takes a drag on the "cigarette"). Yeah man. Mellow, and stuff. Like - what is the program for. What do I want it to do, an shit. And then after a while you can see it all, algorithms, subroutines, data structures, bounds checks. And THEN you get the pencil and paper - here, want some? (cue Indian sitar music)

Re:Code modules start with great intentions (5, Funny)

cmorriss (471077) | more than 7 years ago | (#17039722)

Pencil and paper?! Bah! Why get bogged down with those new age mental encumbrances.

When I get an assignment, I immediately pack my bags for a retreat high atop the canopy in the Amazon. I hunt for food and use the blood of my kill to jot down the design of my project on the backs of baby turtle shells, each representing a piece of functionality. Then I let them loose on the ground and follow them for days. Those that live through the ordeal will have a hollowed place in my design.

Re:Code modules start with great intentions (4, Funny)

Bamafan77 (565893) | more than 7 years ago | (#17041708)

I hunt for food and use the blood of my kill to jot down the design of my project on the backs of baby turtle shells, each representing a piece of functionality. Then I let them loose on the ground and follow them for days. Those that live through the ordeal will have a hollowed place in my design.
I think you misunderstood the chapter on "shell programming". See this is what happens when you bring these VB6-ers over to the Linux world. :)

Re:Code modules start with great intentions (4, Interesting)

EnderWiggnz (39214) | more than 7 years ago | (#17039560)

Wow, just wow.

API's first, always. Everything else is easy to change, but if you eff up the API's, you are in a world of shit when they have to change.

Re:Code modules start with great intentions (4, Funny)

computational super (740265) | more than 7 years ago | (#17040798)

When you are programming, as a general matter, first comes the comments, second the bound tests,

third the job search after you get fired for "wasting so much time" and not being "agile enough to meet the business needs by just getting it done".

Yes, (1)

ObiWanStevobi (1030352) | more than 7 years ago | (#17039492)

Exactly. We have just a small team of coders doing various projects and take pride in modular development that makes it easy for us to use each others classes when we design a program. It's easy to do while in the safe haven of developers hands. Then it get implemented and all of a sudden X feature needs to be implemented and Y data needs to be stored in Z class (unknown before despite countless design meetings). Now we have a choice, Take the time to modify all these nice classes so they have the added capability and still work together nicely and are adaptable, or throw enough code at them to get your features working and data stored immediately (which happens to be when they want it after it has been released).

You just can't think of everything before hand, and after the fact, you just may not have time to do things properly. Although it may save time in the long run, the short run is usually made far more important by users/bosses.

Re:Code modules start with great intentions (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17039766)

Do it right first time around. Writing good code doesn't take more effort than bad ones. In the long run, you save time.

Re:Code modules start with great intentions (1)

LiquidCoooled (634315) | more than 7 years ago | (#17039874)

When painting a picture, a pencil sketch can give you an idea of the balance without wasting time.
If you start with oils and change your mind part way through it becomes a lot more troublesome to modify.

Coding is the same - sometimes you just want to see something working to test the scope of a plan.
If you produce production code first time everytime then congratulations to you, personally if its something new it will go through a number of rough sketches.

Agile is for those who have mastered the basics (4, Insightful)

CaptKilljoy (687808) | more than 7 years ago | (#17039950)

The parent post illustrates an important point about Agile clearly.

If:
  • your team can't say yes to nearly all of the points on the Joel test [joelonsoftware.com]
  • if you spend more time fighting fires than working on your project
  • if you couldn't honestly say your team is better than average
  • if your managment is more focused on getting it out the door than getting it right
then Agile is not going to solve your problems. The basics of good software development have to be there first.

Agile helps a good team become excellent, it doesn't fix the problems in a dysfunctional team.

Re:Code modules start with great intentions (5, Insightful)

ShieldW0lf (601553) | more than 7 years ago | (#17040122)

Good reusable code is empowering. Make them aware of it by giving that power to them. Example:

Just last week I got asked to put some quick hacks in one of my clients sites to allow for some more discrete rights management for their client-facing site because they had one large client ask for it.

I could have written an extra page that those clients get redirected to, some dangling crud in the database to support it and maintain it in an ever growing parallel with the rest of the system, or some other ugly hack that leads to unmaintainable code. That was specifically what they asked me to do.

Instead I proposed that I extend the internal rights management used for employees to handle the client side of things, which was quite a bit more work, and a fair bit more expensive, but "Oh by the way, if we do it this way, I can trivially exploit this change to allow you to also discretely control rights for all this other functionality your clients are exposed to, and allow you to do it on a client by client basis in the future without needing to pay me to change the code."

Don't just tell people that in some abstract fashion your "good coding techniques" are superior to the crufty crud that seems to work fine. Think of all the things that become trivial for you to deliver because of those good coding techniques, and make them part of the package.

In other words, don't tell them you can take 5 days to deliver a "good" implementation that delivers the same functionality as working 2 days to deliver a "cruddy" implementation.

Instead, tell them you can take 7 days to deliver a "good" implementation, and it will include all this extra functionality that they weren't asking for but what the hell, it's good value and it's the right way to do things too, so why not.

If you can't find some way or another to make doing it the "right" way pay extra dividends that users can appreciate, maybe it's not really the right way...

Re:Code modules start with great intentions (1, Informative)

Anonymous Coward | more than 7 years ago | (#17040680)

The mock up code is supposed to become live code, you refactor constantly as you go. If you don't spend a significant amount of your time refactoring then A) you are not doing anything remotely agile and B) it's entirely your fault.

That's the neat thing about agile, you can implements pieces of it at the team level--pulling the responsibility for certain things down a few rungs. Your refactoring time isn't scheduled separately but becomes part of your standard quoted times. Generally this should also improve your quoted time because it's much easier to work on fully factored code.

It's not in any way lying, cheating or being sneaky--it is, in fact, just programming well. If you are not constantly refactoring your code, talking to your co-workers and interacting with customers (at least a marketing rep) whenever you have the chance, then you're really not much of a programmer.

Re:Code modules start with great intentions (1)

umghhh (965931) | more than 7 years ago | (#17041786)

Yes indeed - I just had a discussion about such crap today. I told project manager that this prototype stinks and he told me that they know and they requested from the responsible subcontractor to design things in a proper way. Sa we are all happy and hope fort he best. As always.

But coming to TFA - what good practices have anything to do with agile programing or any other fashionable piece of crap that some 'gurus' try to sell us for big bucks? Keeping your senses and brains sharp, listening to customer as well as designers and testers etc - what is new here? Why should I pay for a book that brings nothing that common sense wouldn't tell you in the first place (if you had it available and were ready to use it OC)?

Maybe it is good to repeat it for the slaves of fashion on managment floor or for newbies but I doubt the former understand and the later care anyway. The project manager I talked with today understood what I said. Did he change anything - no 'cause he could not, as the decisions were made elsewhere and subcontractor is doing things according to its budget and understanding of our requriements which are written (Oh gosh) in english i.e. he does what he wants and how he wants.

Life is a tragedy and a comedy - whether you cry or laugh is your choice and just about the only one you can make.

Agile Poster (-1, Offtopic)

refriedchicken (961967) | more than 7 years ago | (#17039110)

First post of an agile reader.

Buy? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17039126)

I think the Slashdot readership collectively has enough sense to avoid the 'Agile' hype... though I'm more and more concerned that the reviewers will buy into anything that's committed to paper.

Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan. This is asking for disaster, yet it's so popular that you can't avoid it on trendy tech blogs and even places like Slashdot that are supposed to be "for nerds."

Nerds KNOW better.

Re:Buy? (0, Troll)

Anonymous Coward | more than 7 years ago | (#17039236)

I'm afraid you've made it very clear that you haven't read the book and don't understand what the hype is actually about. Please refrain from "knowing" in the future unless you can back up your opinions with some credible insights.

Re:Buy? (4, Insightful)

bryanthompson (627923) | more than 7 years ago | (#17039294)

Okay, that's just idiotic rambling from one who obviously has no Agile experience. Agile programming means planning for things to change, as we ALL know they do. It means designing with flexibility in mind--knowing that when plans, features, behavior, etc., needs to change, you've structured the program in a way that makes it easy to do so. It doesn't mean 'not having a plan' or free-form programming with no structure discipline, but it sure is easy to write off the entire idea by portraying it so :rolls eyes:

Re:Buy? (0)

Anonymous Coward | more than 7 years ago | (#17039846)

That's your opinion... and incidentally, by labelling my post "idiotic rambling from one who obviously has no Agile experience," you've made it pretty easy to write off mine, haven't you? Sounds oddly familiar to something you seem to have a problem with.

Something to think about.

Re:Buy? (4, Insightful)

Mydron (456525) | more than 7 years ago | (#17040132)

Your synopsis falls into the idiotic rambling category. You have no clue what agile is about.

Agile programming means planning for things to change. . . . [Y]ou've structured the program in a way that makes it easy to do so.


This is completely wrong. Agile recognizes that change inevitably happens but that it is chaotic and unpredictable. The mistake you've made is that you assume you can predict the change. This is precisely the mistake that Agile seeks to address. Agile recognizes that it is not likely that you (or anyone else) will be able to predict the nature of changes in the future.

Nowhere does agile prescribe anticipating where code is likely to change. In fact, quite the opposite, agile touts the notion that you build for today. Tomorrow you refactor what you built today. Agile proponents understand that it is often a complete waste of time to build adaptive frameworks that depend on gross assumptions about the kind of changes that are predicted (rather than known).

Agile does have a plan. The plan is: code something that works and build tests that test what you've code against what requirement the code is supposed to satisfy. The code and the test are built together using whatever information is immediately available.

Mod parent up (please) (2, Insightful)

Taagehornet (984739) | more than 7 years ago | (#17040682)

Quoting Martin Fowler [martinfowler.com]

Two of the greatest rallying cries in XP are the slogans "Do the Simplest Thing that Could Possibly Work" and "You Aren't Going to Need It" (known as YAGNI). Both are manifestations of the XP practice of Simple Design.

The way YAGNI is usually described, it says that you shouldn't add any code today which will only be used by feature that is needed tomorrow. On the face of it this sounds simple. The issue comes with such things as frameworks, reusable components, and flexible design. Such things are complicated to build. You pay an extra up-front cost to build them, in the expectation that you will gain back that cost later. This idea of building flexibility up-front is seen as a key part of effective software design.

However XP's advice is that you not build flexible components and frameworks for the first case that needs that functionality. Let these structures grow as they are needed. If I want a Money class today that handles addition but not multiplication then I build only addition into the Money class. Even if I'm sure I'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, I'll still leave it till that next iteration.

One reason for this is economic. If I have to do any work that's only used for a feature that's needed tomorrow, that means I lose effort from features that need to be done for this iteration. The release plan says what needs to be worked on now, working on other things in the future is contrary to the developers agreement with the customer. There is a risk that this iteration's stories might not get done. Even if this iteration's stories are not at risk it's up to the customer to decide what extra work should be done - and that might still not involve multiplication.

This economic disincentive is compounded by the chance that we may not get it right. However certain we may be about how this function works, we can still get it wrong - especially since we don't have detailed requirements yet. Working on the wrong solution early is even more wasteful than working on the right solution early. And the XPerts generally believe that we are much more likely to be wrong than right (and I agree with that sentiment.)

The second reason for simple design is that a complex design is more difficult to understand than a simple design. Therefore any modification of the system is made harder by added complexity. This adds a cost during the period between when the more complicated design was added and when it was needed.

Now this advice strikes a lot of people as nonsense, and they are right to think that. Right providing that you imagine the usual development world where the enabling practices of XP aren't in place. However when the balance between planned and evolutionary design alters, then YAGNI becomes good practice (and only then).

So to summarize. You don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to it because it increases the cost of modification even if it costs nothing to put in. However you can only sensibly behave this way when you are using XP, or a similar technique that lowers the cost of change.

Re:Buy? (1)

Dragonslicer (991472) | more than 7 years ago | (#17041078)

Go back 20 years, and I think that was just called something like "separation of interface and implementation", "separation of concerns", or "information hiding". I guess "Agile" is easier to type, but it doesn't strike me as substantially different. The more things change, the more they stay the same.

Re:Buy? (3, Informative)

endrue (927487) | more than 7 years ago | (#17039478)

"Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan."

You have not accurately represented Agile Development, you have created a misrepresentation so that you can disregard it more easily. Either you do not know what Agile Development is or you are too lazy to honestly critique it.

Please read the following Wikipedia entry for a more formal definition of the logical fallacy you have committed: http://en.wikipedia.org/wiki/Straw_man [wikipedia.org] .

Re:Buy? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17039552)

That would be the latter, actually. I am indeed to lazy to tell people what they should already know.

I spent a couple days reading about 'Agile' methodologies. No, that's not enough time to learn everything about them, and no, I am not an expert. However, I do not believe I need to know every detail of 'Agile' to realize that it is a seriously flawed way to look at development.

Yes, I severely oversimplified, and yes, that could be taken as a straw man if I based my own opinion on simply that or was attempting, with that statement, to argue 'Agile' fans over to My Side of the Fence. I was not, however, so I don't feel too bad about my logical issues in this particular instance.

It's a comment on a review, not a full-fledged "Why You Should Avoid This Crap like the Plague" dissertation. I disagree with you, but don't really care enough to attempt to change your opinion. :)

Re:Buy? (1)

StarvingSE (875139) | more than 7 years ago | (#17041330)

How, may I ask, do you develop? Do you even develop for a living? If you don't, then you can't really make any criticism on agile methods.

Traditional methods (waterfall, prototyping, etc) are just a carry-over from physical manufacturing. You specify requirements, design the product, produce it, sell it to customers, and provide regular maintenance. No one ever stops the assembly line in the middle of an automobile plant saying "whooooaaa hold up, our customers want 4 more square feet in the trunk and the steering wheel on the right side, back it up!." However, this scenario happens all too often in software. Make the wrong design decisions early, and requirements changes later in development can potentially be very costly. In fact, some projects just start over because it's cheaper. Software is a different beast because it is intangible.

Agile methods aren't "planning to not have a plan." Agile's plan is to prepare for future change, and involve the customer in the development process to make sure they are getting exactly what they want. This helps ensure much higher quality in software.

Agile is new, and it's still an immature science with less research behind it than other methods. Is it the silver bullet to software quality problems? Probably not, but then looking for one is a pipe dream. I personally believe a combination of traditional design and agile is the best way to go.

Re:Buy? (2, Insightful)

E++99 (880734) | more than 7 years ago | (#17039630)

Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan.

According to the article, Agile implies "Let Design Guide, Not Dictate". That sounds a WHOLE lot different than "Don't Design". My understanding is that the idea is to have an ADAPTABLE plan. After all, an inflexible plan is a bad plan.

Re:Buy? (1)

TimTheFoolMan (656432) | more than 7 years ago | (#17040732)

"After all, an inflexible plan is a bad plan."

Rummy? Is that you? How's unemployment?

Re:Buy? (1)

Coryoth (254751) | more than 7 years ago | (#17039808)

Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan.

I'm honestly not sure what you mean. I guess you could do Agile that way if you wanted to, but it is in no way a requirement. You want discipline? Try Specification Driven Design [york.ac.uk] and integrate formnal methods into your agile approach. You want structure? Try something like ESpec [yorku.ca] to provide a single workbench to structure design, development, testing, and formal verification. And as for planning, well its a matter of planning with what you have no, and being open to change - that's not "no plan". If you're curious as to why I'm picking on Eiffel as a language for agile development - I figure the percieved incongruity (that, as is apparent by the examples given, doesn't actually exist) of agile development with a fairly strict, planning oriented language like Eiffel might actually get you to pay attention and see what's going on.

Re:Buy? (0)

Anonymous Coward | more than 7 years ago | (#17040610)

A screwdriver is a good and useful tool, and it's designed for tightening screws. However, you can also use a screwdriver to pound in a nail. Heck, you can do it in at least three ways. That does not automatically make any of them a good idea, nor does it make hammers obsolete or less effective.

I made the mistake of seriously oversimplifying my opinion on this matter, which made it seem that I have no idea what I'm talking about. I do know more about 'Agile' development than you might assume. I still consider it a bad idea, and I believe that within a few years, this position will be vindicated by the decline of this method, which will almost certainly be relegated to the same sort of cult following enjoyed by the Atkins diet and the Rocky Horror Picture Show.

Re:Buy? (1)

Coryoth (254751) | more than 7 years ago | (#17040916)

I agree that there is hype around agile methods, and programs of "how to be agile" that suggest a wide range of practices of dubious extra merit, but package the whole thing up as an "agile methodology" etc. Then again, there is some merit to the approach, and developing early testable specifications of what you intend to develop, and against which you can verify any further code you actually develop, is probably a good thing. Whether having two people sit next to each other to code, or having trendy names for your meetings, etc. has much merit is a little less clear. Agile will undoubtedly remain around, it will just become tempered with common sense and a lot of the hype and trendy named aspects of it will get trimmed away.

Re:Buy? (1)

Brandybuck (704397) | more than 7 years ago | (#17039936)

There are some good parts of Agile Development. But unfortunately, it's greatest impact has been as an excuse not to have a process.

Re:Buy? (0)

Anonymous Coward | more than 7 years ago | (#17040108)

THERE is something I can agree with.

I believe someone else in here said most of these things start with a couple good principles and build a whole lot of crap around them. It's my opinion that the flexibility of 'Agile' programming (I hate typing those stupid quotes in there, but I refuse to use that stupid buzzword without them) is mostly, if not completely, theoretical, and that the benefits it promises are mostly -- again, if not completely -- lost in execution.

Think of the waterfall model... it sounds logical. Then you get into production, bad stuff happens, and suddenly your plan is wrecked, you're spending extra time and money to adapt your project, and the deadline you gave your customer is still there, but now it's utterly unrealistic.

Now think of the same project, started with... 'Agility?' Now you have a goal and a direction, but no solid idea of what exactly you're building, only a set of features and how they have to interact. I have an extremely hard time believing this is a good thing. Not only is this -guaranteeing- the exact kind of "that should not do that, this should work that way" that comes with most methods, it prohibits you from looking at the big picture in any meaningful capacity (yes, I consider that a valuable thing to do).

So that's my long-winded agreement++.

Re:Buy? (1)

sofla (969715) | more than 7 years ago | (#17041020)

EXCELLENT comparison to the waterfall model. Its my experience (ymmv) that almost no one does waterfall in practice, and, equally, almost no one does _insert favorite agile methodology here_ in practice. I tend to think of myself as 'agile' (as opposed to...what, I wonder?), but that's because I tend to define it in terms of the Agile Manifesto (http://agilemanifesto.org) rather than conformance to any specific methodology.

In my opinion, if you read the first page of the manifesto and you find that you agree with their four main points, then chances are you will be more comfortable in an agile environment than a non-agile one. If you're not in one (you'll know) and you'd like to be, pick up a book or two and see if there are ideas in there that you could use. As an example, parts of XP are really good and easy to implement, and other parts (pair programming comes to mind) tend to be less applicable to most teams. Or another example, you can adopt automated testing without necessarily doing full-blown TDD ( aka "only write code when there's a test case that fails" ).

As far as the specific, 'formal' agile methodologies go... leave those to the consultants. zealots, PHB's and other buzzword-compliant types.

Re:Buy? (1)

Brandybuck (704397) | more than 7 years ago | (#17041660)

Actually, most successful software uses the waterfall model. It's the only model that works, so it's why it's being used. In fact, it's the core of Agile! Waterfall doesn't have to be a two year project it can be a one week iteration. As long as you plan before you code, you're probably doing waterfall.

Analyse, Design, Implement, Verify, Deploy, Maintain, Repeat.

Do you try to figure out something about what the customer wants right up front? Do you design the software before you write code? Do you do a full systems verification before you hand it off to the customer? Do you go back and do the same thing for the next version? If so, you're using the waterfall model!

There's nothing in waterfall that precludes pair programming. There's nothing in it that says you can't write unit tests the same time you're coding. There's nothing in it saying SQA can't do integration testing on every iteration.

Re:Buy? (1)

bunions (970377) | more than 7 years ago | (#17040128)

> Honestly... no structure, no planning, no discipline, nothing but planning not to have a plan. This is asking for disaster, yet it's so popular that you can't avoid it on trendy tech blogs and even places like Slashdot that are supposed to be "for nerds."

Hello, first of what will doubtlessly be many uninformed posts whose authors clearly have no idea what a typical agile process involves!

You are only truly an agile developer (2, Funny)

Timesprout (579035) | more than 7 years ago | (#17039172)

when you can limbo dance all the way to the office.

Courage ... (2, Interesting)

Salvance (1014001) | more than 7 years ago | (#17039174)

This was the first book review on here that I REALLY enjoyed. Very informative. I liked the idea of developers showing courage to fight for the right path, although I must add that this is best done without getting emotional or fired up. Courage is great when it is modest and controlled, otherwise you'll just be relegated to an even darker corner and reassigned to mainframe Cobol development.

Re:Courage ... (1)

obender (546976) | more than 7 years ago | (#17040952)

After reading your comment I realized I didn't even read the review. And your comment caught my eye only because it's next to a +Funny one.

Now I am facing this dilemma: should I scroll up and read the review? That's like three maybe four page-ups.

Nah, I have to set a limit. Next time I'll be reading the articles if I go on this path.

My methodology is mediocrity (3, Funny)

Anonymous Coward | more than 7 years ago | (#17039188)

So instead of:

The guy who wrote it is no longer here, and no one knows how it works.

It goes something like this:

The guy who wrote it is so stupid, they promoted him, and everyone knows how it works because we all were forced to completely rewrite it.

Re:My methodology is mediocrity (0)

Anonymous Coward | more than 7 years ago | (#17039410)

There's a little more to it than that. If you can't plan something in a myopic
several day worldview, then the big big problems never get solved. I'll take a monolithic
requirements-design-spec-implement-test cycle over Agile any day.

I fear that Agile leads to A.D.D.

Re:My methodology is mediocrity (1)

PianoComp81 (589011) | more than 7 years ago | (#17039418)

So instead of:

The guy who wrote it is no longer here, and no one knows how it works.

It goes something like this:

The guy who wrote it is so stupid, they promoted him, and everyone knows how it works because we all were forced to completely rewrite it.

More like: The guy who wrote it is so stupid he's no longer here, and everyone knows how it works because we all were forced to completely rewrite it.

At least that's what I've seen in my limited experience.

Not just for codeherders anymore (3, Interesting)

neimon (713907) | more than 7 years ago | (#17039208)

"Things like Working for Outcome (in other words, don't blame people for bugs, find out how to fix them and fix the process that caused them) and Criticize Ideas, Not People. Or avoiding the pitfalls of making quick hacks without trying to understand why the hack was necessary (Quick Fixes Become Quicksand). They finish up the chapter with a key word I personally feel is absolutely necessary in software development -- courage. They put this in the context of Damn the Torpedoes, Go Ahead. In other words, if the code you are working on is stinky, and you'd like to throw it away, don't be afraid to bring that up. Or if code you are in the middle of building suddenly becomes the wrong direction, stand up and explain that (being sure that in both circumstances you have alternatives for getting it on the right track)." I try to teach a) help desk people b) network engineers c) operators d) everyone I can ...to do these very things. It's called "giving a shit about your work and how it affects other people." Also known as "doing a good job." 'nuff said.

Enjoyed This Book Myself (5, Informative)

Rhett's Dad (870139) | more than 7 years ago | (#17039258)

I read this about two months ago, and mostly enjoyed it. I don't remember anything earth-shattering or particularly enlightening from it, but then again I had previously read some other books that probably put a damper on what this book had to teach me:

  • Pragmatic Version Control
  • Pragmatic Unit Testing
  • Pragmatic Project Automation
  • Ship It!
  • Extreme Programming Explained
  • Art of UNIX Programming
  • Practice of Programming

Seems like most of what the Agile book had in it was for me a rehash of the three Pragmatic books. So, to me, a good book by itself, but I'd recommend the three Pragmatic books instead of you have the time for that much reading.

Re:Enjoyed This Book Myself (1)

kfg (145172) | more than 7 years ago | (#17040568)

I'd recommend the three Pragmatic books instead of you have the time for that much reading.

And if you don't, guess what?

Surprise! You're a code monkey, not a programmer.

Which is all well and good if that is the path you chose in the first place. It's a living and someone has to do the assembly line type of work.

But if you had something else in mind when you were 16 sitting in your room at 3 A.M. thinking "Oh, wow man!" it's time to make some changes.

KFG

Good development practices... from an Indian?!? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17039318)

Hang on... one of the authors of this book is an Indian? The whole premise of "hold on, don't touch that module" in real life revolves around shitty code written by Indians who lie on their resumes and fuck up everything they touch. EVERY situation that I came across when I was a contract developer was created by some dumbass Indian. Suffice to say, I will in no way purchase a book about development that was written by an Indian.

Re:Good development practices... from an Indian?!? (4, Insightful)

Rhett's Dad (870139) | more than 7 years ago | (#17039524)

Can't imagine why you posted AC there, stud...

My experience with bad code like that has been when a short-term employee was pulled in and forced to work with a short-term mentality... which actually all falls back to bad managers. When your boss instills the "throw it together NOW so it works (barely) NOW and move on to the next project NOW" mindset into the coding crew, you're pretty much guaranteed to be stuck with smelly code. Who the actual programmer is will have little to do with it.

I will assume for your sake that your limited experience with short-term coders has mostly been around the intersection of "H-1Bs" and "contractor programmers" and therefore you generalize "Indian". One day you'll learn that it's the "short-term" part of this equation that hurts the code quality, and not the coder's non-code-related characteristics.

Re:Good development practices... from an Indian?!? (0)

Anonymous Coward | more than 7 years ago | (#17039894)

... pretty much guaranteed to be stuck with smelly code.

No, that's just curry.

Re:Good development practices... from an Indian?!? (0)

Anonymous Coward | more than 7 years ago | (#17040048)

I will assume for your sake that your limited experience with short-term coders has mostly been around the intersection of "H-1Bs" and "contractor programmers" and therefore you generalize "Indian". One day you'll learn that it's the "short-term" part of this equation that hurts the code quality, and not the coder's non-code-related characteristics.

I was a contractor with all different companies for 8 years. I worked with lots of contractors, American and Indian, and we often went to work on some of the same projects together. I know what that short term thing is like... nasty. But Indians always managed to write the worst possible code, and didn't give a shit. Most of the time they were just copying samples from me or another American, and copied and tweaked, not really having any clue as to what they were doing.

Re:Good development practices... from an Indian?!? (0)

Anonymous Coward | more than 7 years ago | (#17039612)

Hang on... you're a racist? I will in no way take advice from a racist.

Feature design documents are... (0)

Assmasher (456699) | more than 7 years ago | (#17039384)

...all you actually need. Good code comments are nice, and explicit variable naming (instead of lazy naming) are pluses as well.

"I have to implement feature , the requirements doc (if any) can be found at: A synopsis of the feature is: In order to satisfy those needs architecturally, I've decided to implement like because we want to avoid using because it prevents us from in the future..."

These docs are usually a page in a half for a complicated feature that has a potentially confusing architectural design.

The problem isn't in what you do up front or at the end, it is making a developer keep a document up to date. We're incredibly hard working about some aspects of our profession and ridiculously lazy about others ;). Every feature that is implemented at my current company results in the developer(s) producing an informal design doc that is used by the architect (myself) to look out for gotchas/caveats/black-holes and offer helpful suggestions. This usually takes about 5-10 minutes in my office. After check-in and assigning the feature as 'complete' to QA for starting the test plan, there's another 5-10 minute review using the same document and asking "So what changed? What did we forget the first time? Ok, add that to the doc, send me a copy and I'll file it..." This way if, God forbid, a dev gets hit by a truck or just up and leaves we don't have to worry about having no idea what they've done and/or what they are doing at this time. Just one of many different ways to solve this problem that doesn't require exotic or strange practices.

Re:Feature design documents are... (0)

Anonymous Coward | more than 7 years ago | (#17039768)

Is everything done under the threat of a thorough mashing of ones ass? Sorry, couldn't stop myself.

Worth a read (5, Informative)

Taagehornet (984739) | more than 7 years ago | (#17039402)

Martin Fowler has written a few words on the subject Is Design Dead? [martinfowler.com]

Highly recommended, grab a cup of coffee ...or two ;)

what a coincidence (1)

hitchhacker (122525) | more than 7 years ago | (#17039426)


I'm about to finish Venkat's semester long class on software engineering at the University of Houston. Actually I have a team demo in a few hours! (what am I doing on Slashdot.. hehe)

I've been very impressed with Venkat's teaching and am convinced that Agile development models are beneficial for commercial application development. The main advantages are its adaptive planning and methods for predicting how long development is going to take mixed with customer communication.

That said, I'm not yet convinced that it is appropriate for OSS development. He's giving a talk next week about just that, so maybe my opinion might change.

-metric

Re:what a coincidence (1)

zurmagus (409978) | more than 7 years ago | (#17039868)

I'm in Venkat's Software Enginnering class also. When I read the opening quote I immediately recalled him saying that in one of the lectures so I just knew the name Venkat would follow it.

He is an excellent professor (but sadly he is only teaching for one more semester) and his viewpoints on software development are always insightful. Anyone who has an opportunity to take classes from him or go to a development conference where he will be speaking should definately take advantage of it.

Everyone can learn something about software development from Venkat, regardless of your thoughts on agile methods.

Re:what a coincidence (0, Redundant)

hitchhacker (122525) | more than 7 years ago | (#17039932)


neat.. good luck on your demo, btw. :)

-metric

Re:what a coincidence (0)

Anonymous Coward | more than 7 years ago | (#17041434)

I'll second Venkat as an excellent speaker. His talks at the NoFluffJustStuff.com weekends are always good.

You call that agile? (4, Funny)

ShaunC (203807) | more than 7 years ago | (#17039486)

It's clear that to be an agile programmer, you simply have to Create Catchy Techniques and learn how to Capitalize On the Shift Key. I'm about ready to Pry Out my Eyeballs...

Re:You call that agile? (0)

Anonymous Coward | more than 7 years ago | (#17041912)

I Fully Agree. Agile Development is all about Spouting On about Agile Development. The plan with any programming ideology is to make money on books, seminars, lectures, confrences, etc. Capitalize on Capitalism. I read the first book on XP ("eXtreme programming eXplained") and will admit that it was fun experimenting with it back in its early days. After skimming a few more books on the subject, I got bored. Methodologies are pretty boring. Its just more management and process.

The Pinkies, they say STOP! (4, Funny)

mollymoo (202721) | more than 7 years ago | (#17039626)

Am I the only person who had to Stop Reading the Book Review half-way through because of Capitalisation Overload? There Are other ways to emphasise or to indicate a "phrase from the book" which are much Less Annoying Than Doing This.

Re:The Pinkies, they say STOP! (4, Interesting)

sammy baby (14909) | more than 7 years ago | (#17039832)

There Is Historical Precedent For This.

(Unfortunately, that doesn't make it any less annoying...)

XP [wikipedia.org] , arguably the 600 pound gorilla of the "agile methodologies," was created by Kent Beck, Ward Cunningham, and Ron Jeffries. It was a direct outgrowth of their work the "Chrysler Comprehensive Compensation (C3) System," and information about their brand new methodology was publicized on a little web site Cunningham had put together.

It just so happened that the "little web site" was the very first Wiki [c2.com] . One of the side effects here is that since each of the XP principles got its own page, it also got its VeryOwnNameInCamelCase. The weird capitalization of the rules is an artifact of agile methodologies' debt to the wiki format.

Or something. I think.

Re:The Pinkies, they say STOP! (2, Informative)

ruben.gutierrez (913239) | more than 7 years ago | (#17040832)

Those are TOC sections.

Re:The Pinkies, they say STOP! (1)

antispam_ben (591349) | more than 7 years ago | (#17041972)

I always found john DVORAK's columns to be annoying, though I think in the one or two that I've read in more recent years, he may have dropped the habit of making every tenth word bold.

arrrggghhhhh (3, Insightful)

mlwmohawk (801821) | more than 7 years ago | (#17039634)

I just can't stand it. How many books and programming fads must we endure in our careers?

"Agile" programming? ATF, sorry, but come on.

Like all the other programming fads, there are elements of good standard practices that, if you've been writing code for any length of time, already do, but then they go on to preach their own brand of mumbo jumbo.

Now, some PHB is going to want to push "agile" programming. Just stupid.

OK, rant. THE CUSTOMER SHOULD NOT DRIVE DEVELOPMENT. There I've said it. The customer has no figgen clue about what development is or means.

Short story: I was working at a company years ago, a VP of development wanted to be able to dial out and use a terminal programs on his PC from our office phone system. I asked him, point blank, tell me exactly what you need. He responded, "I just need to be able to connect to a modem and dial out." (exact words burned into my brain)

So, we bought $20,000 worth of phone equipment that did just that, alowed a PC's modem to be plugged into a wall, and dial out.

He came to my office and said, I can't use this system. I asked why? He said the modem banks weren't "hayes compatible." I looked at him, told him his exact words after being asked "exactly" what he needed, and he said (rather annoyed) "well, you should have known I needed "hayes compatible."

Moral of the story: the user don't know squat about what they want, let alone are able to navigate the technical landscape.

As engineers, we have to learn with the customer knows and apply it to the program, but do not confuse this with letting the customer drive!

Re:arrrggghhhhh (3, Insightful)

chromatic (9471) | more than 7 years ago | (#17039714)

The customer has no figgen clue about what development is or means.

If the person paying you to write software doesn't get to tell you what the software should do, who does?

I went to a fancy restaurant like that once. You pay $150 and get whatever the meal of the day is. Unfortunately, the main course was salmon and I'm allergic to fish, so I left. I heard it was nice, though I've never gone back.

Re:arrrggghhhhh (3, Interesting)

mlwmohawk (801821) | more than 7 years ago | (#17039952)

If the person paying you to write software doesn't get to tell you what the software should do, who does?

The customer does not pay me to "write software" they pay me to provide a tool that helps them accomplish a task. It is a fine line, for sure, but an important one. It is up to me, and any other engineer, to understand what our customer knows and apply it to what ever we are developing.

Letting the customer drive the product is a bad idea. Too often the customer is reluctant to see beyond their immediate needs, alter their thinking, or accept new ideas. So, while you are letting your customer do your thinking for you, some competitor that knows better, is building something better that will put you out of business.

In my previous example, I let the customer drive the modem technology choice rather than spec it out myself, it it was a mistake. I should have known better than to have a system that was not hayes compatible, but the customer did not "require" it.

Ultimately, the customer will be dissatisfied with anything they have a hand in producing, because it will be limited by their own immediate needs.

Re:arrrggghhhhh (2, Insightful)

turgid (580780) | more than 7 years ago | (#17041314)

Ultimately, the customer will be dissatisfied with anything they have a hand in producing, because it will be limited by their own immediate needs.

...and their own imagination.

Can someone please inscribe this on a granite tablet and install it in the British Museum for all to see?

Re:arrrggghhhhh (3, Insightful)

Ramses0 (63476) | more than 7 years ago | (#17040010)

"""He responded, "I just need to be able to connect to a modem and dial out.""""

Engineer says: "B.S. - Be Specific", what is your app, what is the requirement, why do you need to dial out, what do you need to connect to, etc. And in any case, once the customer asks for "X", signs off on it, and it turns out they really needed "Y", it's best to get that over with as soon as possible and start working on "Y".

The user actually knows *exactly and precisely* what they want, it's just that they have a tough time expressing it most of the time, and it's quite probable that what they want is not possible in the timeline / budget / etc. that they have allocated for that need.

So, figure out what a customer *wants*, keep them FAR away from anything remotely technical, but make sure the technical decisions that the engineering team makes satisfy what the customer *wants*.

--Robert

Re:arrrggghhhhh (1)

mlwmohawk (801821) | more than 7 years ago | (#17040126)

The user actually knows *exactly and precisely* what they want, it's just that they have a tough time expressing it most of the time, and it's quite probable that what they want is not possible in the timeline / budget / etc. that they have allocated for that need.

I stongly disagree, I've been doing to stuff for a while, and let me tell you, I witnessed people resisting wordprocessors in the office because they thought they were more complicated, harder to use, etc.

The customer who is used to using typewriters will NEVER be able to help you spec out a word processor.

They DON'T understand what technology can do and thus can not fully understand how to apply it.

This is a very detailed discussion, and probably not slashdotable.

Re:arrrggghhhhh (2, Insightful)

Harri (100020) | more than 7 years ago | (#17040058)

The customer makes decisions in business terms, not in technical terms. It's your job to translate their business needs into technical needs - and to ask the right questions to be able to do so. You're the expert about the technology - but you're not the expert about their business.

Re:arrrggghhhhh (1)

mlwmohawk (801821) | more than 7 years ago | (#17040272)

The customer makes decisions in business terms, not in technical terms. It's your job to translate their business needs into technical needs - and to ask the right questions to be able to do so. You're the expert about the technology - but you're not the expert about their business.

A previous post reminded me about early word processing adoption.

In the late 70s and early 80s, there was serious resistence to word processors, because people didn't want them. They saved paper, made tasks easier, allowed better formatting, etc. It took software engineers that knew better than their customers to bring this product to market, despite resistence to the idea.

The same can be said about any "innovation." Your customers will never innovate. They will want you to make exactly what they do a little easier. They will NEVER see the problem differently, and thus innovatively, in such a way as to change the nature of what they do, and make it vastly easier.

Think about word processors, spreadsheets, CAD, P.C. board layout, etc. These are things that would never have been born if engineers actually listened to the customers. They were made because we ignored what the customers said they wanted, but instead, learned what our customers knew, and applied what we know about software to their business. We revolutionized their businesses.

Re:arrrggghhhhh (2, Interesting)

Harri (100020) | more than 7 years ago | (#17041124)

For sure, it's possible for engineers to invent things that customers wouldn't have imagined. But those innovations are still going to have to produce business value for the customers, or else the innovations are of no use (or nobody will pay for them, which is just as bad for the engineers).

It's still possible to say to the customer "We can make exactly what you do a little easier, for $X, or we can provide you with the following extra benefits to your business for $Y - which would you like?". Ultimately, it's the customers' decision.

Re:arrrggghhhhh (0)

Anonymous Coward | more than 7 years ago | (#17041672)

You are getting to the heart of the matter, which is based on well-known prejudices. Techies are smarter than business people, and believe they could do their jobs 10x better than they could.

Remember, the business majors were the $%^^offs who were out drinking on Thursday nights in
college with easy courses while the engineers were busting their tails.

Am I Missing Something? (4, Insightful)

Petersko (564140) | more than 7 years ago | (#17040162)

Short story: I was working at a company years ago, a VP of development wanted to be able to dial out and use a terminal programs on his PC from our office phone system. I asked him, point blank, tell me exactly what you need. He responded, "I just need to be able to connect to a modem and dial out." (exact words burned into my brain)...So, we bought $20,000 worth of phone equipment that did just that, alowed a PC's modem to be plugged into a wall, and dial out...He came to my office and said, I can't use this system. I asked why? He said the modem banks weren't "hayes compatible." I looked at him, told him his exact words after being asked "exactly" what he needed, and he said (rather annoyed) "well, you should have known I needed "hayes compatible."

So you, the technology expert, bought $20,000 worth of equipment on a one sentence verbal spec... and it's HIS fault?

Isn't this a rather collosal, and unforgiveable, failure on your part?

Re:Am I Missing Something? (1)

mlwmohawk (801821) | more than 7 years ago | (#17040468)

So you, the technology expert, bought $20,000 worth of equipment on a one sentence verbal spec... and it's HIS fault?

Well, trying to make a long story short, it wasn't merely verbal, he did sumit a requisition, it was approved, etc.

It didn't make a difference, he didn't even know what he wanted,

Well, naturally. (2, Insightful)

Petersko (564140) | more than 7 years ago | (#17040574)

"It didn't make a difference, he didn't even know what he wanted,"

Well naturally he didn't. If he knew exactly what he wanted, he'd just order it himself.

I don't have quite the background that some here do (6 years in support followed by 8 years in development), but even early on in my career I knew that "tell me exactly what you want" never, ever works. Even for relatively trivial things.

I'd like to know how you found hayes-incompatible equipment though - that must have taken some work!

Re:Am I Missing Something? (1)

DerekLyons (302214) | more than 7 years ago | (#17041180)

So you, the technology expert, bought $20,000 worth of equipment on a one sentence verbal spec... and it's HIS fault?

You're suprised at that?
 
Reading Slashdot one finds an endless parade of excuses from IT workers why every failure, big and small, is not their fault. It's always the boss, the methodology, the particular shade of green on the walls of the office bathroom...

Re:Am I Missing Something? (1)

nosfucious (157958) | more than 7 years ago | (#17041728)

I'm blaming the people skills of most geeks. I.T. people tend to be less people oriented. Gross generalisation alert: For some reason the more tech you are the less people and vice-versa.

I.T, whether programming, database management, system administration or whatever, is all about working for a business, run by people. Please them, and you'll get the job done, right. (I'm guilty of forgetting users. Occasionally I need to pour a large glass of perspective and soda).

I remember my University days, precious little was taugh about dealing with people, only a little more on what makes buiness "tick". And some rudimentary maths and accounting.

Solid design streaches from the top of code or wiring lay out, right through up to working with the customer/customer manager for the spec. Fail to get the spec right and you're sunk from the beginning. Good management AT THE BEGINNING helps a lot and gets this right. If the management fails, there are generally early signs, but get the hell out of that project before it starts to smell.

A little more engineering/people management skill probably wouldn't go astray in most tech courses. The uber-geek will still be an uber-geek, but the real people would probably benefit.

Enough perspective and soda for today thanks barkeep. I'm off.

Re:arrrggghhhhh (1)

chaotica1974 (572461) | more than 7 years ago | (#17040192)

I used to think like this as well, but as I've been on more and more projects, I've found that an interview with the stakeholder is typically well worth the time taken, even if they don't know what they want, you can provide options and allow them to pick. Hindsight is always 20/20 but I promise you that if you ask the tougher questions by learning the business process behind it, your job will become much easier.

Re:arrrggghhhhh (1)

mlwmohawk (801821) | more than 7 years ago | (#17040374)

I used to think like this as well, but as I've been on more and more projects, I've found that an interview with the stakeholder is typically well worth the time taken, even if they don't know what they want, you can provide options and allow them to pick. Hindsight is always 20/20 but I promise you that if you ask the tougher questions by learning the business process behind it, your job will become much easier.

In my original post I say, point blank, we have to learn what the customer knows. We have to be smarter than the customer, we have to know what they know AND what we know. Only then can we really provide the service sor which we get paid.

Re:arrrggghhhhh (1)

Quintios (594318) | more than 7 years ago | (#17040396)

I'm probably going to get flamed for this, but I have to ask: Why didn't you test the system against his computer? Seemed like he was asking for a specific solution to his problem (the problem of not being able to dial out using HIS computer). Maybe I'm missing the point here, but it sounds like you never verified that the equipment you were installing worked with the existing equipment, i.e. you installed equipment that was not compatible because you never verified that it would work with the existing installation. Having a non-tech person telling you what he needs, without further extensive questioning, is pretty bad.

Re:arrrggghhhhh (1)

mlwmohawk (801821) | more than 7 years ago | (#17040578)

I'm probably going to get flamed for this, but I have to ask: Why didn't you test the system against his computer? Seemed like he was asking for a specific solution to his problem (the problem of not being able to dial out using HIS computer). Maybe I'm missing the point here, but it sounds like you never verified that the equipment you were installing worked with the existing equipment, i.e. you installed equipment that was not compatible because you never verified that it would work with the existing installation. Having a non-tech person telling you what he needs, without further extensive questioning, is pretty bad.

This was, in fact, over 20 years ago, but it is a lesson I remember.

We did verify that it worked. We worked with the phone systemm company, tested it out, and we were able to dial out, just fine. It just didn't use ATDT commands. We were able to configure the terminal programs just fine.

Re:arrrggghhhhh (1)

Coryoth (254751) | more than 7 years ago | (#17040536)

Short story: I was working at a company years ago, a VP of development wanted to be able to dial out and use a terminal programs on his PC from our office phone system. I asked him, point blank, tell me exactly what you need. He responded, "I just need to be able to connect to a modem and dial out." (exact words burned into my brain)

So, we bought $20,000 worth of phone equipment that did just that, alowed a PC's modem to be plugged into a wall, and dial out.

He came to my office and said, I can't use this system. I asked why? He said the modem banks weren't "hayes compatible." I looked at him, told him his exact words after being asked "exactly" what he needed, and he said (rather annoyed) "well, you should have known I needed "hayes compatible."

So your inability to elicit detailed specifications from a client means you should simply ignore the client? I'm not sure I follow. Did you really expect the guy to spell out in glittering detail all his very particular needs, many of which he may not think of on the spot, from a single direct question? You didn't think that a single sentence specification was begging to be fleshed out, went and spent $20,000 on the basis of that first pass spec, and then blame the customer?

Yes, customers are very poor at being able to immediately tell you, in glorious detail, there precise needs leaving out absolutely nothing. That doesn't mean you ignore them, that means you actually spend time talking to them trying to develop the specification. In principle the goal of agile development is to do exactly that, and to help the customers imagination along by providing him with intermediary working models to help elicit the deeper implicit needs as early as possible. The aim is to work with the customer to help the customer actually understand what their own implicit specification is, and that means a certain amount of back and forth is required. It means asking questions like "why do you want this?" so you can determine what other requirements are driving things, or hidden in the basic request. If you had, instead of taking his first pass as the complete spec, sat down with the guy and tried to work out what he needed, perhaps providing examples and explaining what the current spec would mean for him along the way, you could have avoided spending $20,000 on a system he won't use.

I'm beginning to think that working with customers to develop a specification is actually a suffciently hard job that it should be a specialised position - lord knows enough developers seem to have little in the way of an idea about it. Perhaps the task of interacting with the customer, and having the patience to carefully tease out of them exactly what their requirements are, then converting those requirements into a specification easily and clearly interpretable by a development team; p[erhaps that's a full time job in and of itself.

Sales Engineer (1)

antispam_ben (591349) | more than 7 years ago | (#17041772)

I'm beginning to think that working with customers to develop a specification is actually a suffciently hard job that it should be a specialised position - lord knows enough developers seem to have little in the way of an idea about it.

There's a job title of "sales engineer" though too often the person AND the job the person fills falls way short of the goal.

Re:arrrggghhhhh (1)

budgenator (254554) | more than 7 years ago | (#17041776)

"I just need to be able to connect to a modem and dial out."
you should have asked, "Our digital PBX system isn't compatible with a computer modem, can we run a decicated phone line to your computer which will cost about $500.00 to install and $45.00 a month afterwards instead spending $20,000 on a bank of PBX modems?"
People don't know what they want or need, they only know what they think they want or need, the hard part is first getting their wants and needs to coincide, then to get their real wants and needs and what they think they want and need to be the same. They hate telling you because if they clearly tell you what they want and you deliver it and it ain't right it's hard to blame others.

Re:arrrggghhhhh (0)

Anonymous Coward | more than 7 years ago | (#17041928)

Dont you guys get it? That was Martin Fowler, trying to make a case for Agile.

Honestly, Agile sucks. What all these processes tries to do is to turn developers into replaceble corporate entities. I have yet to see a process that believes people are the key, not the process iteself.

Save $10.18 by buying the book at Amazon.com! (0)

Anonymous Coward | more than 7 years ago | (#17039960)

Barnes and Noble is selling this book for $29.95, but Amazon.com is only selling it for $19.77!

Save yourself $10.18 by buying the book here: Practices of an Agile Developer [amazon.com] . That's a total savings of 33.99%!

Looks like an affiliate link to Amazon (2, Informative)

antispam_ben (591349) | more than 7 years ago | (#17041410)

Rather than click parent's link, this plain-text link takes you to the same discount:
http://www.amazon.com/Practices-Agile-Developer-Pr agmatic-Programmers/dp/097451408X [amazon.com]

Or if you still don't trust MY link, go to amazon.com and put in the title Agile Developer.

Fair disclosure: I have used books for sale through Amazon, though not this one.

Time For Study (1)

blueZhift (652272) | more than 7 years ago | (#17040056)

Nice review. This just reminds me again that I need to take time out regularly to study not only new technology, new methodologies. Thanks for pointing out what appears to be a good book!

Example from a real project (2005) (1)

Seku (1033542) | more than 7 years ago | (#17040076)

"... Nobody here is really sure what the code does, the programmer has left. We think that the ?answerset methods were added as part of an incomplete implementation without disabling the static behaviour which we think is of no use. If this doesn't make things clear than can we continue by phone .."

Agile organizations (1)

hebcb (984915) | more than 7 years ago | (#17040620)

There's a lot of focus on the methodologies the Developers need to focus on to achive agility. For me the biggest challenge in my current organization has not been the developers doing things the agile way but getting the customer (or in our case product development... the customer's representative) to be able to think in smaller, self-contained chunks. Some of this may be that we are dealing with a complete rewrite of an existing system... perhaps agile is better suited towards incremental improvements of an existing code-base rather than a "port" style project. In summary, our biggest hurdle seems to have been getting the product sponsors to think in smaller chunks. Not in us implementing an agile methodology within engineering but rather across the organization.

My "Job Interview" Book (0)

Anonymous Coward | more than 7 years ago | (#17040704)

I found this book used, and love it. Nothing in it is "new," of course, but the little bits of wisdom are very nicely organized and presented. I thumb through it the night before a job interview, and I always am able to pick something out that helps me.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...