Slashdot Mirror
You Call This Agile?
JoelonSoftware's most recent piece is about some of the fallacies in "Agile" software and some of the issues within it. We use Agile in some parts of the company, and have had success with that -- that said, there's always the peril that happens when development and other parts of the company have...miscommunication, which sounds like the problem described in Joel's piece.
Anytime that the process concerns dominate making product, supporting product, doing business, making money, you're in the soup. Any process, methodology, tool, language, whatever can be used to make product. And any process, etc. can become an idolatrous religion. Except Linux, of course.
"we use Agile in some parts of the company..." I bet this company isn't doing so hot SINCE YOU'RE ON /.!
I think one of the blessings and curses of methodologies, in this article's instance, "Agile" (ha!), is they are their own universe. So, unless there is something within the methodology that is self-contradictory methodologies don't have fallacies. Methodologies are theses, usually tepid ones at best.
Methodologies are someone's or some group's or some company's idea of a way to successfully accomplish a task, project, etc. Fortunately for all who sell these (vapor)wares, methodologies never fail, they merely suffer from those who have improperly used them.
Methodologies then become the convenient whipping boy for work not done satisfactorily. Sigh.
Peel away the layers, eventually it all still boils down to knowing what you want to do, knowing how to do it, and doing it with a strong instinct for balancing things that matter and things that don't. Methodologies won't do that for you, good project managers will.
(Some of the very best and most successful projects I worked on were with a friend who I consider to this day to be one of the best project managers I ever knew (and I knew many). He used no methodology, but had incredible instincts and a strong will. He knew how to handle time frames, important (and not-so-important) crises, difficult workers, and how to prioritize. It's a shame he didn't get better recognition - he might have had he "used a methodology". I found it ironic he was ostracized/admonished by the company, but he continued to be their go-to guy for the important work.
Bottom line, "Agile" isn't. But "Agile" is just one of a long list of bit players for methodologies in IT.
This article appears to be written by Captain Obvious and his sidekick, Common Sense.
Yes, it is nice to have a dogmatic approach to programming, but ultimately it really boils down to "what course of action will have the greatest benefit to the company?" It has always been this way (even outside of software development) and it always will.
...miscommunication, which sounds like the problem described in Joel's piece
.Net for the latest report release, then into testing mode preparing another test release. All the while trying to convince my supervisor of the need for structure, project management practices, and tools to make our life easier.
Miscommunication? He's talking about context switching, which is an all too common and necessary evil in small shop development.
In any given week I can switch from architecture design to business systems analysts, back to VB6 coding for legacy app maintenance, up to
All that context switching definitely has a negative effect on my productivity. My supervisor asked me to tag tickets with time estimates when I closed them out. No biggie, but the shortest I'll tag a ticket for is 30 minutes. Originally I had said 1 hour, but my supervisor vigorously disagreed with my estimate of context switching's effect on productivity.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
... isn't the whole issue with interuptions. That can be handled differently depending on the work (if you are making life-saving heart monitor software, you had better fix a bug the moment it comes up... if you are making some tool that other developers use once a week, a bug isn't that big of a deal)
The real advantage is illustrated in the age old swing cartoon. By using scrumm and delivering sprint demos often to the user, they can see how their money is being spent, and can present requirement changes to the user faster, thus eliminating the need to make resounding changes right away... Agile development anticipates requirement changes, instead of ignoring it like past methodologies. Is it the best? Probably not... is it a step in the right direction? You bet your ass...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
He has capacity to speak his mind, as he took intensive courses on writing and expression in university, but that doesn't detract that his ideas are his and to each idea there is the opposite side that has just as many positives, if presented correclty.
Aglie development works, but only if people can be trained. Training is something that is omitted when it is decided on whatever model you want to adhere to. Remember we are all just animals and the more training we get, the better we are at it.
Agile process is based on feedback, and therefore programmer must be trained to appreciate and nuruture feedback from his practices too. Programmers need candy too, for rewards, and that candy is a feedback from wroking code. Given, if you are writing a disk driver, feedback is limited, compared to game developer, writing graphics or sound enegines. What Agile brings, is that rewards come at a steady pace, therefore propping up motivation of developer from development side of things. Disk driver developer must find his way to recieve rewards from developing driver code, perhaps thats why compensation is higher for the driver developers, because work has no immediately accessible of stimuli and chances to get negative stimuli, like corrupt disk of the user, are quite high.
If you code not for the sake of itself, I pitiy those people. But then they aren't on the slashdot.
That's pretty much the jist of it. Nothing accounts for every possible situation, not even buzzword methodologies. Do what you think is best.
I wonder if I use bold in my signature, people will notice my posts.
Leakage from an alternate universe far from our own?
Okay, it's a universe very close to our own.
--Rob
Towards the Singularity.
Wake me when software projects start coming in on time and under budget.
I can write any program you want within any time limit you want provided ...
a. I don't have to support it.
b. It doesn't have to work.
Yes, that's funny, but it is not a joke. Processes are supposed to be about functionality and maintenance. A one-off app for a critical issue today doesn't need a process (except how to delete it tomorrow so it doesn't become part of they real system).
And that is where marketing and development differ. Marketing sees the opportunities in selling "support contracts" for code that was rushed out, filled with bugs and features that don't work.
Development only sees problems that they're going to have to fix. And fix today. And fix in the quickest possible way because the customers are complaining about a critical issue. And so forth.
So the various processes (and project managers) are supposed to translate/support both views. Get it out in time to make the sales, with a stated minimum level of functionality and no more than X bugs of various levels.
But, as you noted, it is easy to follow the process as the religion instead of recognizing that it is just a means of getting product ready for shipment so it satisfies marketing, the developers and the customers.
In the hypothetical scenario the customer introduces a critical story in the middle of an iteration. This can and does happen in Agile projects. The only problem is that the team may not be able to deliver something that it thought it would because it will be spending effort on the new story. That is ok. The primary goal of Agile is to give the customer the ability to prioritize work and manage the creation of business value.
Also this aversion toward "context switching" isn't particularly Agile. The idea behind TDD, evolutionary design, and small time-boxed tasks is to work in small chunks. I would argue that the ability to "context switch" developers while still developing value incrementally is the whole point of the Agile approach.
It's for the customer!
To the making of books there is no end, so let's get started
As it currently stands:
50% Flamebait
50% Insightful
New moderation: +0 Inciteful
Seems like this is just another shot in the feud between Spolsky and Heinimer Hansson?
Computational Chemistry products and services.
"This Is Why Programmers Get The Big Bucks. The whole reason you gave them Aeron chairs, unlimited M&Ms, free catered lunches, and the kickass computers with the 30" LCDs is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work." -- Try a 5 yrs old computer, an uncomfortable desk,a chair that must have been bought at some office furniture auction from the 80s, a monitor that makes me feel like I have the eyes of a 75 year old and a boss that says fun is the enemy of productivity....
The government's view of the economy could be summed up in a few short phrases: If it moves, tax it. If it keeps moving,
I think the point missed by both articles (Joel's and the one he is commenting on) are that specific examples are bad. The real problem is making a habit of emergencies. When you fly by the seat of your pants and constantly have engineers fixing emergencies, then yes, it has a very negative impact on their productivity. Once in a while, however, is to be expected and is okay.
Really what any organization should do is instill the resources and culture for proper QA and operational support for developers. If calling the original engineer is the _last_ resort, because QA didn't catch a bug and operations can't fix the problem, thats fine. All too many organizations, however, have an engineer getting called first for a problem that probably should have been caught by QA, or that should have been caught by the operations people. Engineers hunting down problems and finding a reproducible case constantly is really what kills productivity. If the culture is "don't worry, if its broken the engineer who made it can take time out of their current projects to fix it", then your organization is broken.
Why do I see Joel constantly talking about how disturbing it is to "context switch", when sysadmins like myself are expected to handle a dozen or more tasks, most of them "surprise" stuff, daily? Don't tell me "oh, programming is complex"- so are networks.
So, you get unlimited M&Ms, a 30" screen, aereon chair, and get all upset when you spend an unexpected 2 hours out of your 8 hour workday on an emergency, one a week or so. Meanwhile, I'm working on whatever was left in the IT supply room, have to carry a pager, work 10 hour days because I'm doing 2-3 people's jobs- and I've got a half dozen long term project goals...but I'm getting bugged HOURLY to fix the most trivial shit by programmers who can't be bothered to stick paper in a printer?
If Sarah was a sysadmin and had to waste a day collecting her thoughts after spending two hours fixing a mysql database, she'd be fired. You programmers need to stop behaving like prima donnas.
Please help metamoderate.
When a project goes to production, the team must remain with it for a period of N days to handle the deployment problems. One would expect the majority of issues occur within the first couple of days, maybe weeks. Since it is fresh in their minds, they are the ones best suited to correcting issues. Other projects can be available, but fixing the prior one needs to be priority.
Then, find the developers who are good at maintenance programming. I hate working on long projects with the associated paperwork and spending long hours working with the customer trying to tweak a table. Even Scrum requires some process work outside of development. I prefer maintenance programming that gives me a chance to know many, many systems at a high level and then dig into them when there is a problem. This lets me contact Susie for a 5 minute discussion, and then her get back to her project. There are fewer processes because the fix is often smaller, and it has to be done now. It's amazing how many processes get circumvented when customers can't use an app.
The advantage is you get staff members who may not know the deep details of individual products, but have more information about multiple products and are not tied to specific resource timelines. Plus you get developers with timelines who get fewer interruptions. I agree that context switching is bad, whether you are a sys admin or developer. Finding ways to reduce it, even if the solutions means I spend four hours fixing it instead of two, can have other benefits. For instance, being able to say 'Hmm...we had a similar problem last month on this other application, I wonder if it is a similar problem.' then asking the developer a specific question.
It's a different mindset, and it's not for everyone. People who do it have to be able to juggle multiple priorities and handle context switching well. They also need to be able to 'see the big picture' more clearly and understand how product A works with product B in detail (since many issues often fall there and result in group A blaming group B and nothing getting fixed.)
They also have to contain their ego and find the challenges in maintenance programming that are just as rewarding as new development. I love being 'the hero' by solving production problems quickly when no one else can.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
For sure, you sometimes need to incur the penalty of "context switching" when customer needs (or any important situation) requires it. But I read that part as suggesting that any programmer who's paid well should expect to be yanked around on a regular basis, putting out one fire after another, instead of being allowed to devote the attention to his/her primary job necessary to do it well.
And I'm more than a little worried that managers will perceive Joel's article as an endorsement of such yanking.
The Internet is full. Go away.
Pardon the rant, I'm having a cynical week this week.
Used to be, there were generalists writing code. It was possible for one person to understand security, IO performance, database design. Not any more. Now, projects, even individual applications, are too complex to be understood by one person. This forces specialization. Back in the day, system administrators were often the in house generalists, accepted as relatively unproductive coders, but peers in the architecture process.
Nowadays system administrators are rarely asked to help in the application architecture process, most apps are rushed into production with enough crap in them so that we sysadmins are fully occupied devising clever kludges to work around bugs and security holes in already-deployed code. It's a living.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Marshall, that chair cost me $20 at the swap meet. please meet me in my office in 5 minutes so we can discuss your problem appreciating my frugal nature.
It sounds like his criticism is that agile methodologies do not do enough to permit flexibility among the developers. The problem is that the waterfall model, or other traditional methodologies are even more rigid. Most of them delay the maintenence phase until either the end of the software life-cycle or until a team can be organized to tackle the issue, and are based on the idea that a small problem be fixed with a well-planned overhaul, as opposed to a minor tweak. Which do you think would be more likely to provide an emergency fix rapidly?
The problem is that he didn't point out anything that suceeds where agile methodologies fail.
Here is the reply from the author of the originating article: Dmitri Zimine.
They're trying to solve management problems with a development methodology. In other words, let's take all the common sense (and politicking) out of project management and reduce it to a set of mechanical rules which are to be interpreted like an axiomatic system. It sounds like a good idea but it just won't cut it in the real world. The real world phenomena of good project management is so complex it can't be described by a simple set of rules. Frankly, what all of these Agile/XP/Scrum/RUP/supervoodoo methodology arguments have been about is that software engineering project management is as "COMPLEX" as software engineering. Perhaps even more so. It's all about problem solving. The problem it's rarely done right. Motivating people, figuring out how they work, and keeping them productive is hard work. Ironically, if you can intelligently have an argument about the finer points of Agile methodologies, you're probably not the problem. It's the managers who give 'peanut butter' manifestos I'm worried about.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
Joel made the obvious and correct statements that ruby is slow and has no unicode support, and that rails is immature and has not scaled well for alot of people. DHH cried FUD like he always does. DHH is always offended by everyone and always crying about everything because he has such a huge emotional attachment to rails. Its ironic since he spends so much time spreading FUD about java himself.
Being adaptive doesn't mean responding too all interruptions. Remember, one of the key points of Agile is prioritization. You break down the scope so you can focus... not deviate. If interruption messes up your sprint; its because your prioritization (oh no, change control) is broken.
:-)
By the by, agile = cyclical development = waterfall.
/\/\icro/\/\uncher
This article appears to be written by Captain Obvious and his sidekick, Common Sense.
But the thing of it is, you see, is that Project Management has trouble seeing the obvious, and needs a regular kick in the pants.
I am regularly asked about how long some feature or other will take to implement, and generally give a response in terms of man-days or man-weeks. What's fun is to see how this is interpreted by a Project Manager.
"This feature will take 5 man-days to implement."
Manager: "So, it will be ready on (20, 1, 2, 3, 4, 5...) the twenty-fifth. I'll put that on the schedule."
"No. I said 5 man-days. That's not the same as calendar days, and we're shut down the 24th and 25th."
Manager: "Oh, right. So, next Tuesday, then."
"No, I said man-days, which are not the same as calendar days. We don't have any one who can start on this at once, and everyone already has work to do."
Manager: "Oh. Well, can you start on this tomorrow, then?"
*SIGH* And these are the folks who are creating all the pretty PERT and GANTT charts for senior management.
you call this an article?!
"Nae Kin! Nae Quin! Nae laird! Nae master! We willna be fooled again!"
The problem is the word: "Agile." It's a loaded word that means different things.
In terms of "Agile Software Development," it means able to react to customer changes "quickly" and without discarding a large ammount of work. Now "quickly" is another loaded word. In the example article, "quickly" basically seems to mean "after the end of a 2-week development cycle, and before the next one."
Now, in TFA, they're asked to do something that may cause a customer to purchase. This request comes in during a 2-week cycle.
The proper "Agile Software Development" response is "We'll tell you if we can do it in 2 weeks." The criticism is "that's not very agile." Or, "two-week-agile" vs. "right-now-agile."
There are several possible reactions to this request:
Which one you choose depends on multiple factors; two factors are "What is the net revenue impact of this change" and "What is the marginal increase in the probability of the sale?"
If Marginal.Pr[sale] * units > abs (revenue impact lost due to throwing dev cycle), the do it. If not, make them wait two weeks.
Of course, finding values to plug into those equasions is not easy. Believe it or not, management is difficult.
My PERSONAL solution to this, assuming the sale is worth it, is to see if the customer will accept "feature available within 30 days after sale, or you get a 25% refund." Puts pressure on the customer to commit, and gives you time to develop it.
There is no such thing as Agile software. And it is completely ignorant to say "we use Agile". Agile is just an umbrella term for a whole bunch of software development methods. You can say we use Extreme Programming or Scrum or whatever.
In any case, the discussion between Joel and Dmitri has little or no relationship to the relative merits of Agile methods. Dmitri is just some relatively unknown consultant/guru and his individual opinion is just that. In fact, Joel didn't seem to be dissing Agile methods in general, at least not the way I read it. He is dissing Dmitri's doctrinaire approach.
Moreover, the whole discussion is far from illuminating since it is based on a totally hypothetical example. Give me a real world and specific example where we can get a concrete view of what the real priorities and politics of the situation are, and then we can form an opinion on how to behave. Dmitri in his response to Joel talks about
"trust." But if the customer involved is critical to the company, you can be sure as hell that the project manager would (justifiably) get his ass kicked if he ignored the sales request and got all touchy feely about "trust." On the other hand if this is some nundik sales person then it probably can and should be managed by the project manager.
Ultimately, Agile is all about human-centric. As such, you need to understand that organizational politics and behavior can be just as important to the success of a software project as the programming language you choose. Both Joel and Dmitri seem to be ignoring that.
He's not saying "We won't do it." - he's saying "The coder should carry on with their job until a proper decision is made as to whether the context switch is worth it." - he clearly says that the decision as to whether to change what the developer is doing is passed over to the Project Manager to make.
And that sounds right to me. You don't context switch based on getting an email, and you make sure that project managers understand the implications of what they're asking for before you start working on it.
My Journal
For those of us with even a little economics background recognizes Joel's post as a discussion on opportunity cost.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Sure, if you let the inmates run the asylum, you get some ... strange decisions.
The bottom line is that mindless adherence to any rule, even a rule that is supposed to ensure you are more flexible, is bound to make you inflexible.
If you walk in the rain without an umbrella, you will experience wetness. If you tolerate obstructionism, you will experience obstructions.
By way of demonstration I was reading recently about the Privacy Act, a US law which supposedly limits what Federal agencies can do with personal data. The number one reason for citing the Privacy Act these days is for an agency to avoid doing something it doesn't want to do. on the other hand, if it really wants to do something that is illegal under the Privacy Act, it just hires a private contractor to do it.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Look around when you're being shown around your prospective work area. If the printer, copier or fax machine is blinking that it needs paper/toner/reset, you're not walking around in a "high-tech" environment. Developers who can't figure out how to clear a paper jam probably aren't going to be much help when their code won't deploy properly in production, either.
Real developers know how to reset the printer, because they had to do it a couple hundred times when they were trying to figure out how to encode and download the Tengwar fonts to it...
Just junk food for thought...
let me tell you a story of a marketting team that went and harassed developers every 15 minutes for a new flavor of farting bunny... ... anyway, there's a good reason that change requests are prioritized.
By the by, agile = cyclical development = waterfall.
What the fuck kind of waterfall are you thinking of? Waterfalls start at the top, and continually move in one direction: downwards. There is no cycling whatsoever. They're unidirectional.
If you're constantly switching context, someone messed up. Big time.
:-)
I work in a totally different business, a newspaper office to be exact, and sometimes it seems like all I do is switch context. And it's always because someone fucked up. Every time. Maybe someone forgot to tell our department that there was a publication going to print today. Or maybe someone forgot to turn in the paperwork for an ad that runs tomorrow and they need the proof right now. Or maybe they're just idiots and have to explain everything verbally the moment they think of it (think mental diarrhea).
To my mind, yes, I should be able to switch context, and do so often. However, I'm still more than happy to point out that someone fucked up and that needs to be addressed so it stops happening.
There must be a middle ground, and once you reach it (as we have very nearly done here) things will be much happier. Maybe not as smooth as you'd like, and maybe the bean counters and paper pushers won't like the process being so chaotic, but once you reach that middle ground, things aren't exactly bliss, but they're a lot more fun.
So how do you maintain context when things are sheer chaos, anyway? I dunno; tell me when you get it figured out. *wink* Seriously, if you're an OS X user, at the very least keep Stickies running and make a note about what you were doing before you switch. Or write it down on a piece of paper. Sure, use a 3x5 index card with your neato space pen if you think Merlin Mann is God. Or if you're an Emacs nerd, try keeping a todo list via org-mode. Whatever you do, do something to maintain some sanity.
And if you're not a manager, bug your manager to bug their managers to start getting things organized, make salespeople be polite about butting in, and so on; we're not talking about drastic change here (unless, like here, your salespeople have the manners and attention span of five-year-olds.)
Stating on Slashdot that I like cheese since 1997.
Joel's right, software developers should be able to context-switch. But he misses the point of Dmitri's article. Pulling Sarah off the project she's on will have costs, not just in the context-switch overhead but in the disruption pulling her off will cause in projects already scheduled and in progress. The project manager wants the benefits of having her work on the customer request, but is he going to also accept responsibility for those costs? I've been in the situation Dmitri describes, and all too often the answer is a resounding "No.". Dmitri seems to simply be suggesting that those costs have to be taken into consideration.
The process is ONLY as good as the people who use them. You can take a solid methodology in an average, low motivated group and be completely unsuccessful. In contrast, you can take highly motivated, average group with a next to useless methodology and make it a complete success! So what's the real difference?
This is the most common mistake people make. If you need to do it today, you will need to do it again in the future.
The business owner who asked for the one-off will want changes. Or it will turn out to be a good idea that upper management wants to make part of the monthly, weekly, or daily reports.
The "one-off" application is an excuse to kick something out the door without design, documentation, or maintainability concerns. I would hazard a guess that fully a third of production systems are comprised of "one-off" code that was deemed too important to let go.
No matter how much of a hurry you're in, remember that someone (hopefully you) will have to step into that steaming "one-off" pile you're creating today...
I do not fail; I succeed at finding out what does not work.
It sounded nice to hear Joel debunk the agile anecdote as anti-agile and then offer his own real world example.
Problem is his example leave his own "agile" slip showing a bit. His example is as follows:
MS released IE7
This broke a proxy server DLL thingy
Which in turn broke their own Copilot app for a few customers
Which meant he had to divert Ben from a 2 week release, fix the problem, patch the server and delay the release
And this interruption of their agile development was the right decision because it served the customer better
Setting aside the issue of an individual programmer (Ben) deploying fixes straight to production, here's the thing Agile-Ben should have asked: "how the hell did we let the big IE7 release come along, hoze some of our users, interrupt me and probably cause the next release to be delayed?"
Assuming it wasn't part of Ben's agile programming job to regression test and qualify major platform changes for released products, Ben should be saying, "screw this 'it was the right decision to interrupt you' idea. We shouldn't be in the this place to begin with."
The parent's comment is so true it's scary. I think I've had the same conversation a half dozen times in the last month.
You should learn to communicate with people in terms they can understand. There is nothing to be gained fro being right all the time. He asked how long it will take to develop. You gave him some irellevant detail that he doesn't care about.
It's short and to the point...
"Agile isn't.."
A 17 inch Dell CRT?
You lucky, lucky bastard!
Ah, so any developer should know what every other developer is doing so that he can tell management when (someone) can create that feature?
Isn't this WHY we have managers? I mean this quite seriously - if we have to do their job (one of the hard parts of managing, IMHO, even though laying off people is no walk in the park either) why on Earth do they work there?
Of course, we can always go back to the natural language, zero terminology-based talking I guess, but it is rather clumsy:
"How long does take to make?"
"5 full working days for one programmer."
"Can you start tomorrow?"
"No, I am doing X and Z. Meanwhile I have to do Y. Call back in three weeks."
"Unacceptable! You're... you're... hey, this is my red stabler "
Where I work, the response to "We'll be shut down the 24th and 25th" would be "Well, then we will have to work 12 hour days and weekends then, because the deadline cannot be changed"
You may gain productivity at the developer level, but Agile DESTROYS productivity at the DBA and system programmer levels.
We are prototyping some agile development. So far, I have had to REDO a pair of tables 8 TIMES because they keep changing their mind on the definitions. And the project isn't done yet. And when I say redo, I mean drop and start from scratch.
My time (I'm the one DA in the shop and the MVS DB2 DBA)costs the company more than the time of the developer who keeps changing their mind, and it keeps me from helping the other developers. If this evers goes thru the whole shop we will ahve to hire 5 more DBAs, jsut to keep up.
Following is the Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Hmmmm... How does that relate to the article. First, consider the closing line: It says that while placing more emphasis on the left will increase productivity, you should consider both sides of the equation. OK, Joel agrees with that.
Now consider this: Responding to change is more important than following a plan. Doesn't that sound like the conclusion in Joel's article?
Agile is precisely what, in this case, Joel is arguing for.
Stop-Prism.org: Opt Out of Surveillance
"Actually, the ability to look into the inner workings of a failed system and determine the cause of failure and effect a solution are pretty primary to software development (as opposed to writing code, which is only a part of SD). "
True, but the "inner workings" of software have little in common with those of a copier. That's why copier repair experience isn't considered a qualification for software development.
"Unless you want to be a junior coder forever, so you can ignore integration and deployment issues"
I love this one. I guess you forgot to say "Unless one wants". Or did you mean to imply that that I was a "junior coder" on the grounds that I that I must be if I disagree with someone as knowledgeable as you think you are.
Aside from your brilliant use of language... more often than not applied waterfall models DO iterate. The ideal scenario is that it is linear.
http://www.waterfall2006.com/
Sign up now, you need help.
/\/\icro/\/\uncher
How hard is it to redo a pair of tables?
Are you prematurely optimizing them (doing lots of unwarranted extra work)?
Do you need to learn how to use your tools better in some other way--because you now know that you'll need to make lots of changes? E.g. is there some script you should write?
Why are the programmers dragging you into this? Why aren't they doing their own DBA stuff. Once they get something that does what the customer wants, maybe then they should call you in to work your magic on it and make it production quality.
Sounds like time to push back a little.
Good luck!
So far, I have had to REDO a pair of tables 8 TIMES because they keep changing their mind on the definitions. ... and you had to redo a PAIR ... a pair is *2*, yes? Two tables?
... but if that is the case, then you should start getting agile and lift your fat ass and report that this is a problem.
So, taking you literally, they changed their defiitions so often
So, I don't really get what is so hard and expensive in redoing 2 tables
The first rule of agility is: there is no the developers and us the DBAs. There is only the team. You belong to that team as they do. And when you are more expensive than they are your team wastes resources and is far from optimum.
So the next step is just to move this one step further. If they indeed waste time like hell, then they might be agile, but not mature, so someone has to figure why they waste so much time, why they always redo your 2 tables.
And finally: would it better to design a braindead data structure, and keep the tables you design for it, and lose realy big money next year, instead of realizing its wrong and fixing it? A change of mind is not always a bad thing.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
but this link may be informative:
Good Agile, Bad Agile