|
Up to this point the whole thread wasn't making any sense.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
Find a new addiction to forget your old addiction.
Have you tried gambling, alcohol, coke or heroine?
|
|
|
|
|
It's definitely a love hate relationship. I have friends on there that I wouldn't be able to contact otherwise.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
This seems suspiciously like a pro-FB post, but I can't give you an angry face emoji because I like you. Oh, the confusion. 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: This seems suspiciously like a pro-FB post,
Not at all I'm trying to ween away from the FB teat myself. To much drama, baggage, bullshit and just false junk.
See you on FB! 
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Mike Hankey wrote: See you on FB!
Nooooooooooooooooooo!
Jeremy Falcon
|
|
|
|
|
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached.
Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations.
Share your shop's experience.
|
|
|
|
|
I've never seen 100% formal agile in practice, in my experience at least. Personally, that's a good thing. Too much rigidity dehumanizes us. I mean, I understand the need for structure... believe me if a company got halfway there that's probably still better than most pretending to implement it.
Unfortunately, this doesn't just apply to agile.. this industry is a lot of fluff. So many experts that don't know what they're talking about, and only fool the even more clueless. Welcome to technology.
Jeremy Falcon
|
|
|
|
|
Leng Vang wrote: Does any place(shop) doing formal software engineering?
Nope. Everywhere I've been, it's pretty much a free for all when it comes to software development. The saving grace is that I've occasionally had the pleasure of working for and with people that I would call professionals, meaning that they are self-disciplined to formalize their own processes.
Marc
|
|
|
|
|
My company has to get FDA approval, so that requires a very stringent process. So yes, we're doing Agile and have a very detailed documentation process.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: we're doing Agile and have a very detailed documentation process.
Illegal!!!
Agile does not allow documentation!!!
Yes, this was a troll.
Except I'm kind of serious. The code is the documentation in Agile.
This message is only to create controversy which requires you to reply.
However, in replying you will fail.
Please reply soon.
Yes, I'm kidding.
|
|
|
|
|
|
See, I told you so!
|
|
|
|
|
Both ends of the spectrum are a bloody nightmare.
Rarely, however, you come across a place that has found the sweet spot, where the focus is mostly on getting the bloody code written and tested, rather than focusing on poorly-thought-out processes, and where a main part of the process is repetitively demanding requirements.
It's really simple:
0. Tell us what you want, in as much detail as you can.
1. OK, it's done.
2. Tell us what else you want, or what you want different.
3. Iterate 1-2
I will say, however, that the agile morning stand-up is an absolute treasure.
It might be a bit of a pain, but it gets the less communicative members of our community to at least tell everyone what they've done.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Frack, no. We don't have time for that; there's work to do, budget to spend. ![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
|
|
|
|
|
Actually, agile places that don't formalize the process are doing exactly what they're preaching.
|
|
|
|
|
No, not really. Every job I have worked at the code was put together and then documented afterwards. And that includes defense work too, which is supposed to be designed formally.
In fact most non defense jobs there isnt any documentation, the design and test is all in the head of a few engineers.
|
|
|
|
|
so true, often i often hear/experience companies talking agile but in reality the company slacks off a lot of the time
|
|
|
|
|
The most 'formal' development team I've heard of would be the former NASA Space Shuttle software group. I've read a couple of articles about their practices, which were stringent and regimented to a degree hard to believe.
Software Zen: delete this;
|
|
|
|
|
I've read about them too and can understand why they would have to be that regimented. I mean, a bug in the software at most places means someone doesn't get a correct paycheck or something but with that software a bug might mean someone dies!
|
|
|
|
|
I am just about to order another T-shirt that says "Life is too short for best practices".
I am not sure if this in any way relates to your question, though. But I think it does.
|
|
|
|
|
Others mentioned that most places fall on the spectrum from 0.99% and I would agree.
In our line of work, we are often asked to bid a project with incomplete details.
We have clients who "don't understand a wireframe" as we walk them through it! Or worse, they okay the wireframe, and then scream when the product works in a similar fashion... Because they were not paying attention, or could not understand it.
Most of our projects are 3 months in duration. We do formal code reviews. We do Post-Mortems and we do very little documentation (outside of project documentation). We have a small stable team.
But we would not win a bid too often if we had to write a ton of documentation, and do a complete spec review before we ever started. And we had a change management system that worked its way up and down the management chain in order to get things done.
So, I will argue that You SHOULD see a range. Based on what is needed. What the customer wants. And the risk of failure or errors. If errors kill people, then I would imagine a stringent process.
In the end, our clients trust us to deliver what they NEED and listen to the end-users over the managers (who usually have no idea what their employees ACTUALLY do). Which is no different the those who manage programmers 
|
|
|
|
|
I've only done that once, when the dev team I was on was given complete freedom in design and implementation of a project. We decided to go that UML design route, starting with stories, then sequence diagrams, then more formalities. It was a fun experience, but it delayed us finding out that our purely OOP reporting system was as slow as all hell, where with an agile approach would have taken about two weeks to find that out.
|
|
|
|
|
I've never seen it. Starting to doubt it's even real!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
