|
|
This and the previous post are oddly relevant to the third post 
|
|
|
|
|
When managers use that language, it's called buzzword bingo.
When developers do the same, it's secret code for "RUN!!!!!!!!!!!"
|
|
|
|
|
Obviously Wally is boss at maximising reward vs work! 
|
|
|
|
|
I was reading about how a few programmers were able to redo the healthcare.gov website, and could have written it to begin with at a much, MUCH lower cost:
The Secret Startup That Saved the Worst Website in America - The Atlantic[^]
It is not understatement to say that for its importance, this was the worst pile of excrement that software development has ever managed to produce (yes, even worse than Windows Vista). I figure someone has written a good book that discusses how this came to be.
|
|
|
|
|
Is that much of a surprise? Such things usually come from rotten project management, tightest schedules and insane customers who come with great ideas and changes every five minutes. Try working under such conditions and then take a good look at the results.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
You just described agile...
|
|
|
|
|
R. Giskard Reventlov wrote: You just described agile...
...as implemented at many BigCorps, but not all.
FTFY! 
I know that Agile (like every other process methodology in the Universe) has been completely subverted from its true purposes at many BigCorps, but there is the core of Agile and the truth of Agile that is actually something very good.
If you just read the Agile Principles (and if managers didn't subvert that because they need to look like bigshots) then I believe you would find it is actually something great.
Principles behind the Agile Manifesto[^]
You can read those in 5 minutes but they'll make you think much longer. They're really great.
modified 10-Jun-18 15:49pm.
|
|
|
|
|
Very interesting, thank you. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I remember when that came out and I signed it, thinking it was the coolest thing since sliced bread. Now, some 20 years later (I think it's been that long) my more jaded, experienced self looks at that and finds it to be a combination of obvious truths, vacuous fluff and inaccuracies.
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Fluff. Define "valuable" as well as "customer satisfaction."
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Fluff. "Harness change" - WTF does that mean? Is Change a horse? "Customer's competitive advantage" - oi, Dilbert buzzword bingo.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Just not true or possible in many situations. I might agree if it said "working modules" or "working sub-modules", but "working" is a scary concept -- particularly in a piece of software with a lot of inter-connectivity.
Business people and developers must work
together daily throughout the project.
That is the first thing I agreed with then and agree with now.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
That is the second thing I agreed with then and agree with now. Except for the trust part. The reason for code reviews is because fundamentally, I don't trust you, and I don't actually trust myself that much either.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Maybe. Plus whiteboards and Visio diagrams. Then again, I also work quite well with emails and documents. There's a lot to be said for a written document that one can review and annotate rather than poorly transcribed notes.
Working software is the primary measure of progress.
Totally disagree.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Vacuous. There's nothing about agile processes that give's one an inkling of how to go about achieving sustainable development.
Continuous attention to technical excellence
and good design enhances agility.
Agreed.
Simplicity--the art of maximizing the amount
of work not done--is essential.
Agreed.
The best architectures, requirements, and designs
emerge from self-organizing teams.
Um, disagree. This results in architectural islands, creating chaos across the application. I've seen that, particularly in Python and Ruby development (and some Javascript) where each team puts together their own micro-architecture. The result is like the Babel.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
That would be nice.
|
|
|
|
|
Marc,
I really enjoyed reading your comments. I think they've created a great discussion on this entire idea. I agree with you on most of them.
First of all, I think that a lot of what taints the Agile Manifesto Principles is business itself.
There are so many terrible places that are "Agile" and they are nothing close.
Then, there are the problems inherent in the principles themselves such as "deliver working software frequently..." as you pointed out. Most companies are not going to stomach a project without an up-front estimate on time and $$$ so how would this even be possible? How can we just deliver the "minimum viable product" and continually say, "it'll be done some time in the future"?
There are obvious gaps (and even problems) in the principles. As a matter of fact, I don't believe that 99.5% of the companies out there would ever succeed with Agile.
That's because as @sahibgora so correctly pointed out in a message below : "After 25 years and multiple different "methods", I feel that it all depends on the people."
However, there is something that I like about The Agile Manifesto Principles.
When I think of how I do a project on my own, it is an almost exact copy of what the Agile Principles describe.
I bet it is the same way for you.
If I were able to build a team of people who were like-minded, who always kept the goal of what the customer wanted in mind and always drove toward "working software" and people who fought for the product so it would satisfy customer needs (and not fighting for something that the individual dev wanted just because they wanted a technology or whatever) then I think the Agile Principles as stated are fantastic.
But, in 99.5% of companies, it just ain't going to happen. However, I do think that using Agile as guiding principles can help. As guiding principles they are great but whenever a company gets ahold of this type of thing some manager starts thinking about how s/he can manage the process and make his/her life simpler and then it goes down the drain.
I do wonder why you disagree with "working software as the primary measure of success". When I'm building my own software that is totally the ultimate goal. I'm assuming again, you are saying that companies really don't focus on that. However, if the "working software" is the product then I am totally confused by why they wouldn't consider the finished and working product their measure of success??
Great discussion.
|
|
|
|
|
It is pretty obvious that various management people have romanticized the Agile process. I see it as another way to get work done. IMHO, you must determine if the work is suitable for Agile before jumping in. Some projects should be Waterfall until it reaches the stage where core goals are met and a minimum viable product is delivered; then it can switch over to Agile as improvements and additions are made. Unless it's a web site or application, I'm in the camp that says you need to be at version 1.0 before transitioning development processes to Agile.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
Foothill wrote: Some projects should be Waterfall until it reaches the stage where core goals are met and a minimum viable product is delivered; then it can switch over to Agile
That's a really great idea.
However, hybrid ideas like this don't sell books and managers do not like to think about exceptions so we cannot accept it as a valid solution. 
|
|
|
|
|
I would like to think that you're joking but I've seen it in action.... 
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
raddevus wrote: as implemented at many BigCorps by managers, but not all.
raddevus wrote: If you just read the Agile Principles
Read it, threw it away. The core idea is nice (preferable to waterfall) but there is so much bullshit attached.
The truth is that every situation is different and requires a somehwat different approach. What works for one set of people, fails for another for many reasons.
After 25 years and multiple different "methods", I feel that it all depends on the people.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
R. Giskard Reventlov wrote: After 25 years and multiple different "methods", I feel that it all depends on the people.
100% agree with that. You are completely right. I posted an answer to Marc up above (The Lounge - my reply to Marc[^]) that talks about that too.
|
|
|
|
|
Hmm: supposed to be a thumbs up but not showing when I save. Odd. Anyway, all good points raised and discussed.
There is no single right way to do software development but there are a myriad of wrong ways.
I don;t belive that there is a single right answer but there are plenty of wrong ones.Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
R. Giskard Reventlov wrote: There is no single right way to do software development but there are a myriad of wrong ways.
That's a great quote and a great summary of the reality of it.
|
|
|
|
|
Thanks - happy to have made it up!
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
swampwiz wrote: this was the worst pile of excrement that software development has ever managed to produce
It was written in Ruby. What do you expect?
|
|
|
|
|
|
swampwiz wrote: this was the worst pile of excrement that software development has ever managed to produce
I don't know, Minnesota DOT gave it a run for the money.
Minnesota sorry for botched vehicle registration system
It's still a mess...
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
As part of your PIP, I exepect to see our current error reporting dialog replaced with a more elegant solution that has the option to send error reports and show sponsored content. The error reports should contain the offending source code reconstructed via reflection by parsing the exception's stacktrace, and improvements for correcting the code per standards. Code review will be done by myself, please schedule 30 seconds per line on my calendar in outlook.
|
|
|
|
|
the manager/customer can always ask for anything.
your job is to figure out how to do it, effort required ('lines') and completion date [to schedule the 'code review' in their calendar].
'reasonablity' only comes in to it if they expect you to finish it in a ridiculous time frame, for unfair compensation and/or it's something that is not possible with the resources and/or information available.
'what you feel about it' only matters to you and if you want to do it or quit that job.
This internet thing is amazing! Letting people use it: worst idea ever!
|
|
|
|
|
I tend to disagree.
They can ask for anything, true.
However I see it as one of my primary tasks to provide solid advise to customers/managers/... Even if they don't like the answer. It's my job to protect them from their own stupidity, as you will.
So how I "feel" about it is as important as doing the job itself, IMHO.
In the case they keep their foot down, you'll have to give them what they want of course  (But you have a "I told you so" up your sleeve)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
