The craft of programming and software engineering

Yeah, at my day-job, they bought that agile/scrum snake-oil crap, hook, line, sinker, and pole. It is intolerable and is basically a way to make excuses why products end up being late or lacking features, or buggy. It allows for nobody to take responsibility. Management doesn't have to be held responsible for unrealistic expectations, and engineers don't have to be held responsible for failing to deliver. It is awful.
 
Last edited:
Agile and Scrum are the two most overused terms in all large companies today. Nobody has a damn clue what they are but they can explain anything away using just those words.
 
nitro said:
Ya'll might find yourself needing to understand this one day:

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
More...

I found this posting once before by Googling something along the lines of "scrum sucks". I couldn't stop reading it because it was so good. The author really nails it. I am glad I am not the only one that feels this way.

I personallly am sick of the obsession with time estimates and all the sprint BS (at least where I work). It really needs to die a horrible death. I hesitate to recommend that anyone enter the software field because of it.
 
Nothing in Agile Manifesto says you need to implement Scrum, or do anything in particular, only a strong preference for good and sound cooperation in . Unfortunately, managing developers is a hard problem. If you leave developers by themselves, they won't solve business problems and over time will find all kinds of pet projects to work on instead (this can be a very good thing when relevant or in less-busy times, but management won't acknowledge that). Even if you do have a good manager, the next one might botch up and make a mess. So companies, seeking less risks and costs, try to standardize processes and cut corners to save time and money. That Product Owners (PO) generally don't understand tech and don't wanna get involved, doesn't help either.

Though, it's not a process-problem - and cutting corners will only increase total debt in the system over time. So while executives cash in bonuses and pensions, waves of consequences build up for those who are left..

It's really a people problem, a problem with lack of knowledge, experience, diversity in leadership, greed and short-sightedness. None of this is really the fault of developers. Lacking transparency and equal participation, non-managers in any area easily become victim of such "lethal leadership" (book). However, it's also a business opportunity, on longer terms..

Nothing new about this at all. Smaller companies are leaner than big ones, etc. It does help those who feel something is "amiss", but haven't really figured out what it is yet..
 
Last edited:
Scrum and Agile are so over-hyped and so worthless.
To do it right, you have to :
1) understand the problem to be solved; make sure to get feedback from the users
2) design a solution
3) code the solution
4) test the solution

Scrum and Agile are excuses for not doing the above steps properly. With Scrum and Agile, you end up going thru steps 1->4 MANY TIMES...with constant rewriting of code.
 
syswizard said:
Scrum and Agile are so over-hyped and so worthless.
To do it right, you have to :
1) understand the problem to be solved; make sure to get feedback from the users
2) design a solution
3) code the solution
4) test the solution

Scrum and Agile are excuses for not doing the above steps properly. With Scrum and Agile, you end up going thru steps 1->4 MANY TIMES...with constant rewriting of code.
More...

Good points.

Though, you forgot at least:

5) Deploy
6) Maintain solution
7) Remove solution

Anyone in Operations will now see that you've made 4 perfect points, and already more points may be added. If you ask business side, they will add at least 80% of the time spent during the whole project with their stuff too. The more points, the longer feedback-cycle and less overview and flexibility at any stage (ie. planning for removing the solution, which can be good to standardize). If each stage can never be revisited, it's "waterfall" and won't be realistic. This is when people complain about the "other people" not providing perfect work/requirements from the get-go. But complaining helps nobody, other than diverting attention.

For development where there's potential for research and continuous improvement I'm tempted to add:

*) Make short iterations/prototyping and get fast feedback from that in order to improve faster, better and safer.

Unfortunately, corporate environments are usually a bad place to do anything of quality and effectiveness due to all the reasons and perverse incentives we already know.

There is now some push on making cross-functional smallish teams that will collaborate. If companies succeed with this, which requires more top-level administration, time will show if this will improve anything. It may result in managing multiple teams faster, pushing even more of the bottleneck to development and testing/QA areas. Though, I suspect it will devolve into micromanagement-hell from the portfolio management level downwards, eating up even more time from maintenance.

If all requirements are 100% clear and never change, or the project is really really tiny and simple, you may iterate 1 time. In practice, one should always plan to iterate several times or simply build/develop in stages. Don't need Scrum for this, as ordinary PM methodology already has milestones and one can also use common sense to plan ahead.

In the end, everyone forgets about maintenance.
 
Best methodology i found was just 1 programmer and product owner sat in the same room.
Me churning out 50K lines of code a year quite easily doing exactly what the product owner wants.
Any project less than a 100K lines can be done by one programmer.
Front end, back end, database. Full stack.
 
southall said:
Best methodology i found was just 1 programmer and product owner sat in the same room.
Me churning out 50K lines of code a year quite easily doing exactly what the product owner wants.
Any project less than a 100K lines can be done by one programmer.
More...
Amen Brother. At my last contract gig, they had this new chick they hired to do requirements analysis and definition. Since she didn't really document the functionality required fully, I ended up doing 3 RE-WRITES. Oh, did that ever suck.
Had I been able to do the requirements analysis MYSELF, it would have been done right the first time.
Of course, you know who got the blame for this project being late, right ?
 
You must log in or register to reply here.
Back
Top