|
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!
|
|
|
|
|
|
Wow, I had never come across that resource before. That thing is a monster! -- and a bit scary too! It must have taken years to produce.
|
|
|
|
|
|
Yes, been there, done that, safety critical software to DO178 Level A (so that's aerospace software - flight software specifically).
Yes, formal requiremenymts and design (plus full traceability from requirements down through design, code and up through unit test, requirements test and validation). The most stringent part is verification - peer review of all artefacts, unit test with 100% coverage of statements, branches, decisions and as high as possible with MC/DC (modified condition/decision coverage). Oh, and coverage from source to object code because the (Ada) compiler isn't formally qualified.
Don't do that now, but still have close contact with it - it's expensive, but it's what's required by the standards...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Formality seldom survives the first missed deadline.
Software engineering is not a programmer's term; it is a manager's term.
|
|
|
|
|
It is often overseen that a users does not use software like she/he uses a car but uses the services that the software "produces" together with other components like devices, clouds, etc. So software is part of a production site that generates the IT-Services the user needs to run her/his tasks better and more efficiently.
So when looking for professionalism in IT-services the first and most important question is what quality of service the user needs to get the wanted benefit out of that IT-service. And the whole process to define, engineer, develop, deploy and run the production site that delivers the IT-service as "promised" is much more complex than the formal software engineering process delivers today. SO what we need is a formalized approach in Business Analysis that is also delivers quality criteria relevant to the user and not only functional specifications. This is far apart from being a trivial task.
Best regards
UP
|
|
|
|
|
Sure. In government or military contracts.
Mostly what we produce is a _huge_ pile of documentation showing how no taxpayers money was wasted (not including producing said huge pile of documentation).
The unstated aim is to move money from the public sector into the private. An actual working product at the end is pretty much an afterthought. Or if it's a working product, then it's not what the users want - rather what the users bosses they _said_ they wanted several years ago, which leads to the next contract.
That's not to say formal specs don't have their place. Many medical devices will have formal specs due to the risk that lives could be lost if there's a serious bug.
|
|
|
|
|
Government contractor here, and I can concur. A colleague of mine often points out that the the documentation we produce must produce stacks of paper that are tall enough that we can use them to build a fortress to protect ourselves when the auditors attack the castle.  I produced a 1000-page ATR just last month (I didn't actually print it out, though).
Having said that though, I should also mention that I am on a team that is introducing Agile methodology to this heavily waterfall-dominated workplace, and we are making some real headway. One of the keys that has helped us a lot is the use of quality tools: Jama for requirements development, JIRA for issue tracking, etc. Introducing these tools has really helped us to start enjoying the best of both worlds. (That 1000-pg ATR, for example, was automatically generated from our Jama repository.)
|
|
|
|
|
ALL MEN MUST DIE?
The warden of an overloaded prison decided to ease the situation in a somehow brutal way...
He told to the inmates, that from the next day he will line up the inmates from each section (between 20 to 30) in a way that they can see the inmates before them, but not those behind. The guards will but a black or white party-hat on the head of each inmate in a random way...
From back to front, each prisoner have to say what color the hat is on his own head. Those are guess wrong will be executed...
What the inmates can do?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Since you didn't add any other rules, why not take off their hat, look at it, and then give the answer?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I asked the warden - touching the hat punishable by death...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
But the hat is on his head, so it is touching him. Therefore he is already touching the hat and all prisoners die immediately.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: and all prisoners die immediately.
That does fix the overcrowding issue.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I told - the warden is a brutal creature...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
The way I heard it, one guess is allowed to be wrong, if more than one then all prisoners die. You can't turn around, only see the prisoners in front, can only provide one answer.
Very difficult for many, quite simple for those of us who lived in the early days of serial communications and error-prone memory.
|
|
|
|
|
Assuming there is an equal number of black and white hats, the guy at the tail end of the queue can see every hat except his own. He can correctly guess the colour of his own. The guy in front of him uses that and the hats he can see to say what colour his hat is, and so on.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
