June 27, 2020 at 5:00 am
Comments posted to this topic are about the item The Appliance of Science
Best wishes,
Phil Factor
June 27, 2020 at 2:04 pm
Agree completely with your article.
One additional thing to note is that like a religion, "Agile" has acreeted lots of extraneous things, which are rather distant from the original Agile manifesto. It is rather reminiscent of "Life of Brian"'s shoe or gourd.
June 27, 2020 at 5:09 pm
I wonder if anyone has ever done a survey to find out how many of us are left in the business. By "us" I mean the people who used a TRS80, read Computer Shopper, knew how to fix a dot matrix print head with a bent pin, etc. The people who don't just know the "what" but actually know the "why".
WABALUBADUBDUB
June 27, 2020 at 6:25 pm
well, we're at least in our 50s, so...
June 27, 2020 at 8:20 pm
I think the basic Agile argument is not that it's "faster" overall, but that customer engagement is "sooner", more continuous. Not like the "big bang" approach of "give us specs and 12 months" then a belated "did we miss something critical?"
June 28, 2020 at 8:28 am
Don't care what the 'method' is called. Talk to the real users from day 1. Find out what they actually need, not what they think they need or have been told they need. I have been in many projects that got lost in the deep outback chasing some difficult functionality when something simpler would actually have suited the users better. Most users have no comprehension of what might be easy or difficult to implement (nor should they?). Also keep 'management' to a minimum and out of the main communication channels with the real users - the fewer people who get in the way of shared understanding the better. Note that I am privileged to usually work on small-ish projects with direct access to highly-capable users, so YMMV!
Learn from the mistakes. We all make them. There is no pride in claiming otherwise. We are nowhere near being a 'science' yet, but we have to keep trying to get better, and the best way to do that we know about is the scientific method, if we can get to a good starting point. Until then it's little better than anecdote and empiricism - that is not a criticsm, its the best we've got at the moment. More people should record their project progress and report the bad as well as the good.
And yes I have been doing this a while. Started programming in 1971...
June 28, 2020 at 4:01 pm
@ganotedp Yes, I agree that Agile experts are very quick to come out with this as an advantage, but for an old fogey like me, being told this by an Agile coach is like being lectured by a priest on the benefits of being considerate to one's spouse. I always was, dammit. When I started out, we talked to the users the whole time. We involved them the whole time. We had no option because we did a lot of basic commercial stuff and they knew far better than us how it was done. Also, they wanted to automate manual processes rather than do Business re-engineering. We had to understand the manual processes! I was no stranger to doing rapid releases, even in the eighties. Sure I took part in various developments for large corporates that used the classic 'waterfall' or 'big bang' approach, but this was by no means universal. We associated it, at the time, with the large international IT consultancies.
Best wishes,
Phil Factor
June 28, 2020 at 9:17 pm
Would that Factorization had become the dominant development methodology of those and subsequent days...<!--more-->
June 29, 2020 at 7:45 am
Every now and again one of the signatories of the Agile Manifesto will tweet something short and to the point. Usually I breath a sigh of relief because it realigns folk who read the tweet back to what agile practises were supposed to be about.
I think some teams follow agile practises better than others. A few claim to be agile when there are things buried in strata of rock we do not yet have the technology to reach that are more agile.
There are conflicts inherent in any methodology. Real physical deadlines do exist in the real world. I'm not talking about the 95% that turn out to be artificial.
I'm not sure that finance departments and processes are friendly towards agile software development. No matter how flexible the requirements my experience is that the budget is what it is. Just because you increase the revenue doesn't mean your team get to use anything other than your pre-allocated budget.
I also have some doubts over the long term affects on developer behaviour. Forecasting and estimates were a pain and at best a polite fiction but having to do them did make us think ahead. We had to think how different teams needed to mesh together. YAGNI cuts through a lot of guff but at time it's like driving at high speed through fog. Painting yourself into a corner faster than ever then going up on your tip toes to paint yourself further in.
The other problem i have with agile teams is that they have a tendency not to respect the boundaries of their domain. It's convenient for the team to change a data type so they do.......causing a car crash everywhere that data is delivered to, if it continues to be delivered at all. I've seen hermit kingdoms sprout up with local warlords clashing violently on the borders.
There's a huge amount of good that agile can do but it has to be recognised as a disciplined approach, not an isolationist free for all.
June 29, 2020 at 1:50 pm
I have been programming since 1977, getting into the weeds with the Heathkit educational series on analog and digital technology including machine and assembler programming. I have also programmed in Fortran, FORTH, C++, Java, PL/SQL and TSQL. I have used declarative tools such as Oracle Forms. I have worked on large (100 people) and small projects (3 people) using waterfall and agile.
One of the problems of waterfall is that big consulting firms get involved and feel like their value is determined by the weight/number of pages of documentation so it takes months to produce the bloated fluff that adds no value. I have seen large waterfall projects fail because of this. One of the issues I see with agile is that many shops use the word agile to justify bad practices. An example is to emphasize "the conversation" and ignore the written documentation. When that happens you have one person who knows a specific part of the app and it takes a new person weeks to figure out the original requirements so they can fix a bug, add an enhancement or include new functionality. This may include many hours with the subject matter expert and the original developer, if they are still around. In this case the original application was delivered faster because no one had to consider other parts of the database or wordsmith the requirements. After the task is completed, no one goes back to their notes to document what they did because they are on to the next task.
I have been working with databases for over 3 decades. The agile concept of small things done quickly can result in some really bad database designs that are hard to understand and expand and lead to a lot of data integrity issues. I attribute this to the vision of a developer who has insight into a small portion of the application so he creates tables and columns without considering if they already exist or how else they may be used. Often teams do not have a database designer to review the impact of changes.
For those who may not know or who have not read the manifesto recently, I leave you with this, emphasis from my perspective:
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.
© 2001-2019 Agile Manifesto Authors
This declaration may be freely copied in any form, but only in its entirety through this notice.
June 29, 2020 at 2:17 pm
OK, I like the new house you've built. Let's move the front door to the front of the building.
And we're going to need a basement.
June 29, 2020 at 2:59 pm
Good, gitmo!
I am not up on all the agile literature but is there any interest in creating the initial application emphasizing both the left and right prinicples equally?
Marcus
June 29, 2020 at 5:06 pm
Maybe Agile works, maybe it doesn't. Maybe it involves the client more, and maybe the client sees the development take shape more rapidly, but I see, at least in my world, the same developers making the same mistakes of working in small, albeit potentially more responsive silos, and still failing to fully research the big picture of how their changes might impact the other systems in the environment.
I'm still willing to keep an open mind, but I'm not sure I am sold on it yet.
June 29, 2020 at 5:13 pm
OK, I like the new house you've built. Let's move the front door to the front of the building.
And we're going to need a basement.
Yes that could happen. You have to be upfront that it might happen so that the risk is clearly understood and that the product owner takes responsibility for it. hopefully the need for a basement and door somewhere else would emerge so that their absence is merely a source of mild embarrassment to the forgetful.
@hmbacon I too have seen "agile" used as an excuse for slap dash cowboy bodging and winging it by unscrupulous consultants who have latched onto a gullible stakeholder with more power than sense. I have also seen the consultant driven specs that could be used to stress test an industrial shredder. But I have also seen both agile and waterfall projects working well and giving the "customer" what they wanted in a reasonable time frame.
Poor communication begets poor software. Software becomes legacy when people are scared to change it. The speed at which software becomes legacy can be exacerbated by poor documentation which is, after all, a form of communication.
I feel the big problem with agile software development is that decision makers only hear what they want to hear. You can tell them until you are blue in the face that it requires discipline, their active participation and access to key personnel. What they hear is "IT has found a way to give me stuff quick without bothering me or my team. If the office junior is bored I'll let IT babysit them."
Another delusion is that open-source = free software.
August 13, 2020 at 6:51 am
Just to throw in my curmudgeonly 2-cents worth: I would wager real money that three-fourths of Agile's real value comes from the daily stand-up (when they're done properly). That "simple" act of spending a few minutes each day in front of your boss and your teammates having to honestly explain what you're doing (or not doing) and why makes it immensely harder for risk-averse, communication-averse folks to drag down productivity.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply