What do you guys think? Is it a fad? I interviewed with a bunch of guys today that claim they develop with this software life cycle. But they still want to do a classic style Quality Assurance. The workflow is documented via use cases, and supposedly thats more written down than expected. But I'm not sure how they would want me to do QA without something written to tell me how the product works.

Postnote: I do not know shit about "Agile" style software development. I have a degree in Software Engineering. It wasn't anything I covered.

Well, relatively new that is. This wasn't anything I ran into at school either and I just graduated in 2005. It's cool shit though. I've been reading up on certain components of it like test driven development. There's a bunch of different methodologies in it but they basically focus on shorter iterations of development and are much more flexible to a real software development life cycle. It just counters the usual software project that's completely planned from top to bottom (waterfall model) because that doesn't factor in the fact that not all development can be planned so far in advance. It's actually quite unrealistic to expect something like that to fall right into place. Agile development expects there to be considerations and issues that may prolong or significantly change the overall project plan at any given point in time. And as you've noted there isn't much in the way of documentation; just use cases. It drives management insane because they can't plug it into Microsoft Project and get nice, pretty metrics to show to their superiors. With agile development the project is done when it's done not some artificial date.

Well, that's what I've been reading at least. I haven't actually done any of it myself and from what I understand it isn't suitable for every situation. Certain methodologies expect you to be in close proximity with the customer/client but you can't always get that. For these dudes you talked to I'd ask why methodology they're using (scrum, test driven development, etc) just to get an idea of what else to expect.

pixel-eight.com

> Well, relatively new that is. This wasn't anything I ran into at school either
> and I just graduated in 2005. It's cool shit though. I've been reading up on
> certain components of it like test driven development. There's a bunch of
> different methodologies in it but they basically focus on shorter iterations of
> development and are much more flexible to a real software development life
> cycle. It just counters the usual software project that's completely planned
> from top to bottom (waterfall model) because that doesn't factor in the fact
> that not all development can be planned so far in advance. It's actually quite
> unrealistic to expect something like that to fall right into place. Agile
> development expects there to be considerations and issues that may prolong or
> significantly change the overall project plan at any given point in time. And
> as you've noted there isn't much in the way of documentation; just use cases.
> It drives management insane because they can't plug it into Microsoft Project
> and get nice, pretty metrics to show to their superiors. With agile development
> the project is done when it's done not some artificial date.
>
> Well, that's what I've been reading at least. I haven't actually done any of it
> myself and from what I understand it isn't suitable for every situation.
> Certain methodologies expect you to be in close proximity with the
> customer/client but you can't always get that. For these dudes you talked to
> I'd ask why methodology they're using (scrum, test driven development, etc) just
> to get an idea of what else to expect.
>

... in theory, although my manager is doesn't want to give up control, so we're doing it wrongly. I've done it semi-properly in the past (Scrum methodology), and it's great for developers, but it looks like it could be a bit of a bitch for testers because you can end up with a whole bunch of functionality at the end of an iteration that needs to be tested, with no time left to test it. I guess that might just be the way we've used it. If we were doing it properly-properly, we would have used Test-Driven-Development and written automated Unit Tests, so less end testing would be necessary, but you always need some (I used to be a tester, but now I'm a developer).

It would possibly be a bit of a leap, but will open up a lot of doors and give you useful new skills if you can use it.

Not a chance it works. For all I can tell it's one of those thingies where a bunch of guys come up with all fancy names for things, put a trademark on them, and then go sell books and seminars (see: Design Patters, Aspect-Oriented Programming, Neuro-Linguistic Programming, Theory of Constraints).

The main problem is that people who buy the books and get to learn it are not the managers. So depending on the organization it may be very difficult or even impossible to get management buy-in. No buy-in means that they may not care as long as you get things done, but then they are going to have your ass as soon as your first deliverable is late, even if you had daily "scrums" with your client and were very agile as far as they were concerned.

That being said, I agree with the idea in theory. No waterfall model means that you don't get a bunch of people that are paid to do nothing but agree on impossible dates and then go whip developers to get it done for yesterday. Agile values the developers more because it relies on them talking to clients. In theory it's great because clients get transparency on the whole process, and should be comfortable that everything is going to plan because they are involved in checking the plan.

In real life, it doesn't work quite so well. Clients don't want to bother. They don't really want to know what goes on under the covers as long as they get their shiny new features. Then for Agile you really want to have good developers. Otherwise you'll end up with a mess.

Another things is that agile kills the "hero" model. Waterfall projects sometimes fall into panic mode because the plan was too vague in the beginning and was never adjusted to meet reality. So you end up with a bunch of guys who work their ass off to save the day. Management notices this and rewards those guys more than those that had very careful planning and avoided any issues whatsoever.

The irony (and probably why I'm so cynical) is that you have to be "agile" anyway with waterfall due to changing specs, but nobody will reward you extra for that agility. It's all about politics at the end of the day.






[download a life]

> Not a chance it works.

Eh? It's currently practiced to much success in development houses around the globe. Tons of companies even offer corporate training for adopting agile methodologies.

For all I can tell it's one of those thingies where a
> bunch of guys come up with all fancy names for things, put a trademark on them,
> and then go sell books and seminars (see: Design Patters, Aspect-Oriented
> Programming, Neuro-Linguistic Programming, Theory of Constraints).

Design patterns are the shit.

> The main problem is that people who buy the books and get to learn it are not
> the managers. So depending on the organization it may be very difficult or even
> impossible to get management buy-in. No buy-in means that they may not care as
> long as you get things done, but then they are going to have your ass as soon as
> your first deliverable is late, even if you had daily "scrums" with your client
> and were very agile as far as they were concerned.

No denying that.

> That being said, I agree with the idea in theory. No waterfall model means that
> you don't get a bunch of people that are paid to do nothing but agree on
> impossible dates and then go whip developers to get it done for yesterday. Agile
> values the developers more because it relies on them talking to clients. In
> theory it's great because clients get transparency on the whole process, and
> should be comfortable that everything is going to plan because they are involved
> in checking the plan.
>
> In real life, it doesn't work quite so well. Clients don't want to bother. They
> don't really want to know what goes on under the covers as long as they get
> their shiny new features. Then for Agile you really want to have good
> developers. Otherwise you'll end up with a mess.

Yeppers. I certainly can't say I would trust my coworkers to rise to the occasion.

> Another things is that agile kills the "hero" model. Waterfall projects
> sometimes fall into panic mode because the plan was too vague in the beginning
> and was never adjusted to meet reality. So you end up with a bunch of guys who
> work their ass off to save the day. Management notices this and rewards those
> guys more than those that had very careful planning and avoided any issues
> whatsoever.

This I sympathize with. We have one dude who never tests a thing he writes. He just churns out code. He gets to be a hero twice because he gets shit done fast and then when it doesn't work he makes himself out to be a hero when he fixes it. No credit to the rest of us who actually write solid code and test it appropriately.

> The irony (and probably why I'm so cynical) is that you have to be "agile"
> anyway with waterfall due to changing specs, but nobody will reward you extra
> for that agility. It's all about politics at the end of the day.

There's a huge difference there. There's agile development and then there's slapping lipstick on a pig to try to make it look pretty. I do mountains of the latter with the waterfall model. I can't deny the points though; the management types need their pretty spreadsheets and unrealistic deadlines. There are progressive shops out there though and if I find one I'm joining ranks. Even if I can't I plan on employing components of agile development into my workday. There's some good stuff in there.

pixel-eight.com

> > and then go sell books and seminars (see: Design Patters, Aspect-Oriented
> > Programming, Neuro-Linguistic Programming, Theory of Constraints).
>
> Design patterns are the shit.

Ok it was a bit unfair to lump them together like that. The listed have different degrees of value and worthlessness.

Design patterns are useful to communicate what you did, but very often you run across zealots who try to shoehorn anything under the sun in a design pattern. I've even once met one guy who would not write a line of code until he would find a named pattern to put it in. That's not only ridiculous but dangerous. It's one thing to show me a piece of code that works and tell me "I followed the XYZ pattern", but another of telling me "no you can't do it like that because it goes against the XYZ pattern". I find AntiPatterns to be more useful, because they are a handy list of side-effects.

I haven't seen Aspect Oriented Programming in use in any real-world system. It seems like going back to global variables and functional programming, which I don't agree with personally, but I guess some people prefer it. It looks like you can simulate it by using a static class if you badly need it. So I don't think it's the cultural revolution it claims to be. But I could be wrong.

All I've seen from NLP is just crockery sold by relapsing Amway-bots. The most vocal proponents are dubious to say the least: overconfidence without anything concrete to show, employ cult tactics "bring the wife/girlfriend to my seminar", and basically play on the fact that a lot of people will listen to a confident speaker and believe something just because it's on a printed book that sold more than 100 copies (Rich Dad/Poor Dad...).

Theory of Constraints is actually more interesting for programmers, and at least in the parts I've tried for my own use, tends to work. It's similar to the Toyota Production System, a "lean management" approach to things, based on logical premises (hence interesting for programmers). Basically it relies on identifying waste, cutting it, and concentrating on what's important. It does suffer however from the fact that it's a hard sell because it encourages looking at things differently (and people usually focus on a single problem). It doesn't help either that a lot of people involved in the theory pull the same seminar book-selling antics than in all of the above.

> I plan on employing components of agile development into my workday.
> There's some good stuff in there.

Yes there is indeed, but that's a bit different: you are creating your own set of tools an methods that makes you more productive. If you take a step back and look at it it probably won't be 100% (or even I'd say 70%) of any of the silver bullets the different theories pretend to be. And it shouldn't... too many people take it like gospel and end up creating more trouble than solving anything. As they say there is a war between engineers making better fool-proof systems and the universe making better fools...




[download a life]

> > > and then go sell books and seminars (see: Design Patters, Aspect-Oriented
> > > Programming, Neuro-Linguistic Programming, Theory of Constraints).
> >
> > Design patterns are the shit.
>
> Ok it was a bit unfair to lump them together like that. The listed have
> different degrees of value and worthlessness.
>
> Design patterns are useful to communicate what you did, but very often you run
> across zealots who try to shoehorn anything under the sun in a design pattern.
> I've even once met one guy who would not write a line of code until he would
> find a named pattern to put it in. That's not only ridiculous but dangerous.
> It's one thing to show me a piece of code that works and tell me "I followed the
> XYZ pattern", but another of telling me "no you can't do it like that because it
> goes against the XYZ pattern". I find AntiPatterns to be more useful, because
> they are a handy list of side-effects.

Yeah, that's mega foolish and that's a good distinction. You can tell by looking at certain issues what patterns may apply but developers that do the "big design up front" and stuff patterns in end up with more maintenance and inflexible code. I write what I need to write and then refactor into patterns where they make sense. I totally know where you're coming from though because some dudes really need to take a chill pill. I'm a better developer because of all the neat tricks I learned from desing patterns but they aren't a template for development; just a suggestion.

> I haven't seen Aspect Oriented Programming in use in any real-world system. It
> seems like going back to global variables and functional programming, which I
> don't agree with personally, but I guess some people prefer it. It looks like
> you can simulate it by using a static class if you badly need it. So I don't
> think it's the cultural revolution it claims to be. But I could be wrong.

Personally I haven't done anything with it.

> All I've seen from NLP is just crockery sold by relapsing Amway-bots. The most
> vocal proponents are dubious to say the least: overconfidence without anything
> concrete to show, employ cult tactics "bring the wife/girlfriend to my seminar",
> and basically play on the fact that a lot of people will listen to a confident
> speaker and believe something just because it's on a printed book that sold
> more than 100 copies (Rich Dad/Poor Dad...).

I've never heard of that stuff. Is it just a management style?

> Theory of Constraints is actually more interesting for programmers, and at least
> in the parts I've tried for my own use, tends to work. It's similar to the
> Toyota Production System, a "lean management" approach to things, based on
> logical premises (hence interesting for programmers). Basically it relies on
> identifying waste, cutting it, and concentrating on what's important. It does
> suffer however from the fact that it's a hard sell because it encourages looking
> at things differently (and people usually focus on a single problem). It doesn't
> help either that a lot of people involved in the theory pull the same seminar
> book-selling antics than in all of the above.
> > I plan on employing components of agile development into my workday.
> > There's some good stuff in there.
>
> Yes there is indeed, but that's a bit different: you are creating your own set
> of tools an methods that makes you more productive. If you take a step back and
> look at it it probably won't be 100% (or even I'd say 70%) of any of the silver
> bullets the different theories pretend to be. And it shouldn't... too many
> people take it like gospel and end up creating more trouble than solving
> anything. As they say there is a war between engineers making better fool-proof
> systems and the universe making better fools...
>
>
>
>
> [download a life]
>

pixel-eight.com