Practices of an Agile Developer 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.
| Practices of an Agile Developer | |
| author | Venkat Subramaniam and Andy Hunt |
| pages | 184 |
| publisher | Pragmatic Programmers |
| rating | Buy |
| reviewer | Cory Foy |
| ISBN | 0-9745140-8-X |
| summary | A book to become a better developer (even without the agile part) |
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.
Update on the link (Score:3, Informative)
Re: (Score:1)
Re:Update on the link (Score:5, Informative)
Price Comparison Table [addall.com]
Buy.com has it for $2 cheaper than Amazon.
Code modules start with great intentions (Score:5, Insightful)
We have all got our monsters.
Re: (Score:3, Interesting)
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 ge
Re: (Score:1)
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 (Score:5, Funny)
(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 (Score:5, Funny)
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 (Score:5, Funny)
Re:Code modules start with great intentions (Score:5, Interesting)
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: (Score:2)
There are of course different levels of "internal" and if the only client of a class is another class under your control then it is fine to refactor methods that are involved in it's contract.
All this is with the rider that you need unit tests to ensure the code continues to meet it's contract.
Re:Code modules start with great intentions (Score:5, Funny)
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".
Re: (Score:2)
I'm either a project manager, in which case I don't have to answer such kind of questions, or I'm a project developer, in which case the productivity tools will show how far I got (number of code lines, diff/patches, new files, milestones achieved...) and I don't have to answer such questions either. If forced to answer such a question, my answer is usually "within timeframe" (if it's such the case, of course). And if I need to say "thi
Yes, (Score:1)
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
Re: (Score:1, Insightful)
Re: (Score:1)
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.
Re: (Score:2)
Next thing you know you'll be telling me not to do the NYT crossword puzzle in ink...
Agile is for those who have mastered the basics (Score:4, Insightful)
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: (Score:2)
Re:Code modules start with great intentions (Score:5, Insightful)
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: (Score:2)
Sometimes the "cruddy" implementation is all they need. Why should they lose extra time and money to functionality they don't need? To borrow from the previous buzzphrase (Extreme Programming), once the unit test is green its good to go.
Really it depends on the client and the situation. Sometimes (as you suggest) quality, reusability and maintainability
Re: (Score:2)
I work with a couple of people who will code some functionality as quickly as they can so they can brag about how it only took them a couple of hours. Over the next weeks and months you find th
Re: (Score:2)
Re: (Score:2)
But sometimes you just don't have the extra 3 days. For example, I have very strict release cycles, yet what goes into a release is negotiable.
For example, I currently am developing a class where the database takes about 0.25 seconds to return the corresponding row. For 99% of my program, this is fast enough because I'm only lo
Re: (Score:1, Informative)
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 imp
You are only truly an agile developer (Score:3, Funny)
Courage ... (Score:3, Interesting)
Re: (Score:2)
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 (Score:3, Funny)
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: (Score:1)
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 (Score:3, Interesting)
Enjoyed This Book Myself (Score:5, Informative)
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:
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: (Score:1)
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
Audio Interview With Andy Hunt About The Book (Score:2, Informative)
Feature design documents are... (Score:1)
"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 architectur
Worth a read (Score:5, Informative)
Highly recommended, grab a cup of coffee
what a coincidence (Score:2)
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 con
Re: (Score:1)
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 so
Re: (Score:1, Redundant)
neat.. good luck on your demo, btw.
-metric
Re:what a coincidence (Score:4, Informative)
Yes, he's very enthusiastic about whatever subject he's teaching. Too bad he took so much time out of class to travel and lecture at other companies, though.
You might want to read a dissenting opinion [blogspot.com]. Having been on both Agile and non-Agile development projects, my own experience is that some Agile techniques are beneficial for some projects, but anyone who says that Agile is the magic pill that will ensure maximum productivity is both smoking and selling you something.You call that agile? (Score:5, Funny)
The Pinkies, they say STOP! (Score:5, Funny)
Re:The Pinkies, they say STOP! (Score:5, Interesting)
(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: (Score:2, Informative)
Re: (Score:2)
Re:The Pinkies, they say STOP! (Score:4, Informative)
Someone else already pointed it out, but those are the sections. Trust me, I wouldn't have written it that way if it wasn't.
arrrggghhhhh (Score:3, Insightful)
"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: (Score:3, Insightful)
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: (Score:3, Interesting)
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
Re: (Score:3, Insightful)
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 (Score:4, Insightful)
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: (Score:1)
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 typewrit
That's a bad attitude (Score:3, Insightful)
That's a really bad attitude. Granted, there are some Luddites that don't understand technology, are afraid o
Re: (Score:2)
Then give your solution back to them, watch how they get on with it, see what they think of it. Learn your lessons and roll them back in
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:1)
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
Re: (Score:3, Interesting)
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,
Am I Missing Something? (Score:5, Insightful)
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: (Score:1)
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. (Score:3, Insightful)
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: (Score:2)
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: (Score:2)
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 li
Re:Am I Missing Something? (Score:4, Insightful)
Re: (Score:1)
Re: (Score:1)
In my original post I say, point blank, we have to learn what the customer knows. We have to be
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Sales Engineer (Score:2)
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: (Score:2)
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 ne
Re: (Score:2)
Customers know what they want. But they can't express it. Your job is to make sure you both arrive at the same understanding of what the customer wants, and you get there by asking the right questions.
Think about it - I hand you a blank piece of paper and say "draw me a picture". A lot of people have trouble with this - they don't know where to start, they don't know what they want to draw, they don't know what I'd like
Re: (Score:2)
"the customer *usually* has no figgen clue" would be a better way to put it.
Here I am in a position where my company, as a customer, has asked a software company for a piece of software (a Java GUI for the hardware we produce, to be specific) a few months ago, with a number of evolutions on that software. The trouble was, since that company could not afford to have a
Re: (Score:2)
(1) I never said "home PC" I said his PC.
(2) It wasn't an internal (to the PC) modem, it was a modem bank for the office phone system.
It seems like you are assuming that he wanted to dial into the company from his house, and this is completely wrong and not supported by the original post.
Sheesh. The event happened over 20 years ago in a company no longer in business. People are harping on the finer details and specifics are long lost t
Time For Study (Score:2)
Example from a real project (2005) (Score:1)
Agile organizations (Score:1)
Extreme Programming - the Morning After (Score:2)
This is the hangover from Extreme Programming and downsizing. Welcome to deferred costs.
Re:Buy? (Score:4, Insightful)
Re:Buy? (Score:5, Insightful)
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) (Score:2, Insightful)
Re: (Score:2)
- Building stuff fast (Usually a good thing)
- Being ready to refactor if it all goes a bit 'Pete Tong' (Another good thing)
- Writing clear and commented code a junior developer could maintain (Developers will love you)
- Being always ready to assist and/or mentor other programmers where required (Bosses will love you)
Expressed this way, nothing seems particularly contentious, though it definitely de-empha
Re: (Score:2)
You said:
Well, what does it matter, imho this whole agile, XP stuff is made up by crackmonkeys anyways.
If you want to software that works then you need three things:
- One Architect (or a team that acts like one)
- A bunch of highly skilled codemonkeys
- A plan which is turned into a spec by the architect and which only changes ar
Re: (Score:1)
Re:Buy? (Score:4, Informative)
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: (Score:1, Insightful)
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 attem
Re: (Score:2)
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 th
Re: (Score:2)
In that case, GM was practically bankrupt, and they had to take whatever shit the 'waterfall' car design process spat out on the first turn of the crank.
Re: (Score:3, Insightful)
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: (Score:2)
Rummy? Is that you? How's unemployment?
Re: (Score:2)
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 o
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
In my opinion, if you read the first page of the manifesto and you find that you ag
Re: (Score:2)
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
Re: (Score:2)
Software, like hardware, should be planned before implemented. You get blueprints before building a house. You get a diagram before burning the circuit. And you design your software before you write it. Twenty five years of programming life, and I STILL can't understand why people have a problem with this concept.
Yes, you can overplan. The "classic" non-iterative waterfall model fails because of this. But just as bad is underplanning
Re: (Score:2)
That goes without saying. But these same people are the ones who refuse to read Fred Brooks. Most other industry have gotten past fantasy and into reality, but the software industry still insists there must be a magical silver bullet out there.
Re: (Score:2)
Hello, first of what will doubtlessly be many uninformed posts whose authors clearly have no idea what a typical agile process involves!
Re:Good development practices... from an Indian?!? (Score:4, Insightful)
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.
Looks like an affiliate link to Amazon (Score:3, Informative)
http://www.amazon.com/Practices-Agile-Developer-P
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.