[–] roznak 0 points 4 points (+4|-0) ago 

More generally, developers’ work should adhere to the foundational principles....

Jesus, quit the "principles" reasoning!

The best developers don't follow principles, they create principles based on what they need. They don't follow patterns, they invent patterns for what they need. And what is needed depends on the company's needs.

Get rid of these SCRUM teams and you will notice that one good developer will replace one complete SCRUM team when they are allowed to do their work. Take developers that started their careers in the 90's. the period where good developers came into existence because they self-learned it all by themselves.

[–] discobiscuit23 0 points 0 points (+0|-0) ago  (edited ago)

Coding should not be straight forward, as neither is language. The reason why we have this awesome technology that is only a certain percentage better is basically because of semantics. We need more out of the box coders not giving a fuck what they were taught, we need coders that will experiment and have fun with their codes.

[–] [deleted] 1 points 3 points (+4|-1) ago 


[–] WhiteRonin 1 points 1 points (+2|-1) ago 

So back to waterfall?

[–] [deleted] 1 points 1 points (+2|-1) ago 


[–] x1x3x7 0 points 0 points (+0|-0) ago 


[–] roznak 0 points 2 points (+2|-0) ago 

I’ve tried to help those people understand that their organization is doing “Agile” wrong: they’re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend.

WRONG! SCRUM sucks also Agile Software Development experts suck even, bigger!

Claiming that they are doing it all wrong, is a clear indication that you have no clue what programming is. The big giant flaw in by these co called Agile software developers is that they try to "quantify" software development and assume that software development is team work and can be teached.

  • Great software is ready when it is ready, not when time is up.
  • Great software cannot be planned and predicted before, you create a fuzzy goal and ask the developers to create something that does this.
  • Great software developers work efficiently alone. They need to build their code reliably and that does not work when you get some idiot crippling all your code at random locations.

Now brace for impact, anyone that was brainwashed into SCRUM methodology, your life will suck because it is going to take many years to unlearn these bad behaviors. If you came from school and did not develop 5 years ago, then your brain was never trained to be creative and your career is over.

[–] notenoughstuff [S] 0 points 0 points (+0|-0) ago 

Reg. when software is ready, one also has to consider deadlines. In such a case, I would believe that it typically for most cases is a good idea to inform the relevant decision makers that are responsible for the given project or product whether you believe the goals can be reached, ask them how to prioritize, ensure that there are proper fallbacks if the deadline fails, and generally keep them well-informed such that they can take decisions. That does, as you say, depend on the case.

In any case, I strongly agree with you that prioritizing the company and keeping focus on how one can help the company achieve its goals are very important. And here I must apologize, for I believed the blog post cared more about how developers can do a better job, instead it indeed seems to "sell" things to developers, and I think that is similar to a lot of SCRUM marketing, because they tend to focus on how developers can be "empowered" (whether true, false or the opposite...) instead of focusing on how developers can better help the company, which ought to be the focus.

[–] roznak 0 points 2 points (+2|-0) ago 

You need a soft deadline. deadlines are important because then we wrap everything up to a complete functional project.

What would be better is to have a soft deadline, and make developers try to do everything they can in this given deadline with certain directions to follow to. Any good developer will optimize the time and resources because they love to create and also love to win.

This blog post indeed is trying to create a new hype because their previous hype failed. It is the exact same people that tries to cover up their previous mistake by introducing yet another method that will fail exactly the same way.

[–] happydaddy 0 points 0 points (+0|-0) ago 

Project managers superior term: scrum, agile, change management etc. Developer words: don't try to force nine women to deliver a baby in a month! I read this joke today and think its so true!

[–] viperguy 0 points 0 points (+0|-0) ago 

RIGID MEETING AT 9:30 or 10AM for all ruins the entire company!

The 20% of super coders that do over 80% of the hard productivity, leave work very very late and barely can come in at 9:30 AM.

They eventually quit in rage, and the company implodes in less than 18 months. I have seen this three times.

All because of SCRUM+Agile rigid daily meetings too early in the day.

[–] roznak 0 points 0 points (+0|-0) ago 

If you can’t quite manage that, I’d advise you to take on less work in each time period, until you’ve taken on a small enough batch that you can actually get it done.

Massive FAIL! This never works in good programming.

In good programming you look at all the possible issues and then create a multiple dimensional level solution that solves it elegantly. The code will be a little bit more complex but it probably collapse the number of code to 20% of what you would have created.

And if done correctly, this slightly more complex code will be self correcting and self testing where your need for mocking and unit testing will be reduced to the minimum.

Good developers don't write code, they write cathedrals where every part has a function and well thought place.

[–] WhiteRonin 1 points 0 points (+1|-1) ago 

Watch his video. He’s been saying this for a long time.

[–] PutinDid911 2 points -1 points (+1|-2) ago 

lol, railing on Agile in 2018.

[–] the_hidden_metric 0 points 3 points (+3|-0) ago 

The guy who wrote this helped write the Agile Manifesto.