Is there a good book that discusses the horrific original healthcare.gov website?
-
R. Giskard Reventlov wrote:
You just described agile...
...as implemented at many BigCorps, but not all. FTFY! :rolleyes: 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.
Very interesting, thank you. :)
The difficult we do right away... ...the impossible takes slightly longer.
-
R. Giskard Reventlov wrote:
You just described agile...
...as implemented at many BigCorps, but not all. FTFY! :rolleyes: 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.
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 ar
-
R. Giskard Reventlov wrote:
You just described agile...
...as implemented at many BigCorps, but not all. FTFY! :rolleyes: 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.
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
-
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.
swampwiz wrote:
this was the worst pile of excrement that software development has ever managed to produce
Umm Canada's Pheonix Pay system might rival that.... Ashes to Ashes - The Canadian Phoenix Pay System Debacle • McLeod Governance[^] Although admittedly not for the number of people affected. :sigh:
-
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 ar
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.
-
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.
:thumbsup: 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.
-
R. Giskard Reventlov wrote:
After 25 years and multiple different "methods", I feel that it all depends on the people.
:thumbsup: 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.
:thumbsup: 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
-
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(); }
-
:thumbsup: 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
-
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. :thumbsup: 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. :laugh:
-
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. :thumbsup: 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. :laugh:
-
R. Giskard Reventlov wrote:
There is no single right way to do software development but there are a myriad of wrong ways.
:thumbsup: 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
-
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.
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](https://www.twincities.com/2017/09/11/i-apologize-state-confronts-botched-rollout-of-new-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.
