Are we agile or eXtreme or in a scrum?
Heater.
Posts: 21,230
Are any of us here agile or eXtreme or in a scrum?
Recently mindrobots mentioned the major buzzwords in the industry today: "agile", "eXtreme" and "scrum".
As an oldy in the business I see that new methodologies for software construction seem to pop up every few years and take the world by storm.
On the technical side we have gone through flow charts, structured programming, object oriented programming etc and if you listen to the young'n's today that's all Smile and functional programming is what you want.
On the more organizational side we have started with top down design, the waterfall model and come to agile.
Many of these proposals have some good ideas in them but they seem to be rabidly adopted as the "only" way to do something. When I look into them all I see a bunch of authors and consultants waffling on in some vague way about this wonderful new thing that will save you. Of course they are clever enough now a days to throw in that "there is no silver bullet" for your software problems.
"agile" for example seems to sum up the idea that: We don't know what the requirements are, we don't know what the customer wants, even the customer cannot say what he really wants. Therefore we will not try to design the entire project at once but rather take some small part of what a customer says he needs and build that. Then move on to the next requirement, which may well grow from the first. And so on.
That's cool as long as you can pull the customer along, but would it have been a good way to build the software required to get man on the moon or fly a Boeing 777?
Here on the forum we have a lot of very talented software engineers. Just look at what Chip does. Or Jazzed or Roy Eltham, or eric or....there are too many to list, sorry for missing you all out. Look at what they accomplish without ever any mention of agile, extreme scruming or any other such buzz word.
So I thought I have to put the question to them all. Am I alone in thinking all these buzz words are just giberish? Do any of you work in such environments?
Recently mindrobots mentioned the major buzzwords in the industry today: "agile", "eXtreme" and "scrum".
As an oldy in the business I see that new methodologies for software construction seem to pop up every few years and take the world by storm.
On the technical side we have gone through flow charts, structured programming, object oriented programming etc and if you listen to the young'n's today that's all Smile and functional programming is what you want.
On the more organizational side we have started with top down design, the waterfall model and come to agile.
Many of these proposals have some good ideas in them but they seem to be rabidly adopted as the "only" way to do something. When I look into them all I see a bunch of authors and consultants waffling on in some vague way about this wonderful new thing that will save you. Of course they are clever enough now a days to throw in that "there is no silver bullet" for your software problems.
"agile" for example seems to sum up the idea that: We don't know what the requirements are, we don't know what the customer wants, even the customer cannot say what he really wants. Therefore we will not try to design the entire project at once but rather take some small part of what a customer says he needs and build that. Then move on to the next requirement, which may well grow from the first. And so on.
That's cool as long as you can pull the customer along, but would it have been a good way to build the software required to get man on the moon or fly a Boeing 777?
Here on the forum we have a lot of very talented software engineers. Just look at what Chip does. Or Jazzed or Roy Eltham, or eric or....there are too many to list, sorry for missing you all out. Look at what they accomplish without ever any mention of agile, extreme scruming or any other such buzz word.
So I thought I have to put the question to them all. Am I alone in thinking all these buzz words are just giberish? Do any of you work in such environments?
Comments
It is all social engineering - lead, follow, or get out of the way. I just try to follow. There is only so much the mind will tolerate in 24 hours.
Superlatives and fanatics seem to come together. I'll take a good knowledgeble pragmatist any day.
The reality is that a successful businessman is often shrewd.
BTW, nothing is more daunting tha studying linguistics with a bunch of doctorate hungry academics. The words flow, the debates are intense, and nothing much gets said. And the textbooks are even more horrific.
?flowcharts ? Someone decided to deploy some CASE tool made noawadays by a big sw/hw vendor, And I have to program doing flowcharts... that software is so ancient in its whole, so rudimentary, it should be used for uml how difficult it is to make a good interface to draw a couple of rectangles donnected by lines ? They are kidding me, haven't they seen any Modern CAD software recently ? that is a drawing interface not that thing out of the 80s... Assembler rules, at least propeller assembler does
You're not alone. I tend to think these methodologies are thought up by consulting firms to sell coaching services in the new methodologies. I think the management of many companies buys into this because they don't understand what software really is. Management schools often stress a style of management that works well for classic manufacturing where process automation is stressed. But manufacturing software is the easy part, and that's not what we're doing when we write it. So they keep looking for a silver bullet to make software writing conform to their expectations.
When we write software we're creating an algorithm specification in a language which is free from the ambiguity of natural languages. All the up front work of requirements gathering and system specification is needed to feed into this specification. The manufacturing step is running a compiler and putting the bits onto a server for distribution which is the easy part.
The problem is that all the up front work really is required to get what you want. But it seems like wasted effort versus just start coding. However, if you don't know what you want then you are unlikely to find it.
There's never time enough to do it right, but time that can be allotted for rework is limitless.
And "Quality" is something we talk about (and talk, and talk, and...), but it's nowhere taken so seriously that it could get in the way of shipments ("we gotta make our numbers - so we'll have to take them as returns next month.")
Where I am at now, I haven't seen or heard any of it...
It's much easier to quantify the cost of getting it out now (or opportunity cost of not) than to quantify the cost of maintenance.
In the commercial business world, most product managers really don't care about maintainable until there is enough revenue derived from the project to actually care. In the government contract world, it's easier to justify investing in a more maintainable infrastructure. In some ways I feel like there should be no difference, but government work tends to be more focused on the public good for some reason. Government money seems to never be an object whether it's paid for or not ....
As for the buzz-words, I guess they are trying to capture methodologies in "sound bytes" for communicating ideas. If a manager or owner wants such things to be important then fine, but it's not really necessary.
I remembered reading an article last week --
http://www.bbc.co.uk/news/magazine-21337849
"Corporate Speak is a manner of speech which employs complicated and sometimes florid words and phrases in place of more precise, if somewhat every day, speech to give the impression of intelligence and gravitas. The irony being that the language used is often grammatically incorrect, misleading and obtuse and often gives the opposite impression."
Agile gives users the warm fuzzy because they see progress and they get to make suggestions every few weeks. "This text should be bold!" "Can we move that image to he right?" "I think the paragraph should read...". As I doodle on my notepad...
I've built a lot of turds. I'm not proud, but I'm a real good turd polisher.
As a process guy, I run across these at each screening for each new gig.
These are failrly general terms most of the time, but to some folks they mean very specific things. Kind of like "blue" or red" can mean a specific color or a whole range.
Sometime these terms mean the group has avery good understand of how it works well and has tuned it to its best or most efficient. Sometimes it meas they are talking out another orifice instead of the mouth.
Nearly always these terms are mis-used by folks (that may or may not understand them) to circumvent required process. Typically some budget minded individual will try to skip a meeting or review or test, to save a few dollar or a few hours. When this abuse occurres, it usually costs hundreds of time more dollars and hours to fix it. Which is why they need a process guy to prevent this.
So, yes, these words are usually gibberish, but the are not supposed to be and don't need to be. They can actually be kind of cool when used correctly.