What rules are you talking about? The agile manifesto specifically says, "we value Individuals and interactions over processes and tools." It sounds like you are too focused on rules, and have lost sight of what Agile truly is.
on one end of the spectrum you can formally spec out the entire system and wait a lifetime to get something that doesnt do what you want, using the waterfall model, due to too much involvement
on the other end of the spectrum you can describe what you want to the developers over a beer in the pub and wait a lifetime to get something that doesn't do what you want because of a lack of involvement
scrum/agile should be the lesser of both evils, 'hey, this week can you create the signup and onboarding flow, and login and forgot password please' where you break the big picture down in to meaningful deliverables you can iterate on to demonstrate constant progress to the stakeholders.
This can be done merely by having shorter release cycles. No need to do all of scrum.
if it devolves to 'working harder' that means the entire team is unable to make correct time estimates or worse, is ok with being unable to make realistic time estimates.
Log message problems can be fixed (maybe by a different team, though), if that were the worst thing, it wouldn't be a problem. The problem is systemd is crappy architecture, and you don't want to build stuff on top of crappy architecture to get it embedded deeply within the system, you want to keep it flexible and replaceable. That's why this project is good even if you never use it, because it will improve the quality of the software you do use. And those people who do like systemd can use it.
What is the point of a daily meeting? It's not for status updates (otherwise you wouldn't need a tracker). It's to make sure programmers are working. That's why.
The stuff we're programming in Silicon Valley is closer to what the village idiot does than what Einstein did. It's all a bunch of crappy workflow software.
ok, you completely misunderstood or you are trolling. Examples.
1)A person doesn't know how to write Javascript or CSS. Can you trust this person to finish the frontend featureset by next week? No, you can't.
2)A person doesn't have good estimation skills. Can you trust this person to estimate when they will finish? No, you can't. Another example:
3)A person has finished their work within the estimate every sprint for the last six months. Can you trust this person to correctly estimate when they will finish? Yes, you can.
So.... What is the difference between the second and third example? One of them has skill in estimation, and the other doesn't. That's it. So teach that person how to estimate. There are ways to do that.
1) The team itself should choose the process because imposing process company-wide by business execs is bullshit. If you have a consultant come in and impose a method, that's reverse of what should happen.
2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)
3) All you need are three principles and those are, "release code often" "keep your code clean," and "push back against managers imaginations" by focusing on reality: what state the code is in now.
Again he reiterates, if process is imposed from above instead of chosen by the team, things will go wrong. He's kind of echoing Fred Brooks here, who said, "The teams need a process, but they choose it on their own."
Agile (more specifically, scrum and derivatives) is a tool managers use to keep programmers on task, and to get them to work harder. In that way, it begins from a position of lack of trust, you use it because you don't trust the developers to take care of things.
Ultimately that is the opposite of Agile, which says, "We value individuals and interactions over processes and people." If you don't trust your developers, the focus should be on improving the skill of your developers so you can trust them. The best agile methods focus on improving the soft skills of the programmers, rather then beating them down or 'controlling' them with process.
There is, though. Right there at the top it says, "We value individuals and interactions over processes and tools." Is Agile a process? Primarily it's not. Ask your consultant what they are doing to value individuals over processes. Watch the blank look of fear, followed by a stream of BS coming out of their mouth.
Being strongly typed makes a language bad for large applications? No, being strongly typed is what keeps it from turning into an impossibly incoherent mess like large JavaScript programs.
It took me a long time to understand why Java is popular, because I couldn't really see a use for it. Finally I realized it fits one niche really, really well: you can put a bunch of low-skill developers to work in Java, and they won't mess the code base up beyond ability to work in it. Oh, they will make it really ugly, but those same developers in C would end up with something completely broken and unsalvagable.
No, it's fun! I actually tried APL in a job interview once. They said, "Use any language you want." "Really?? OK." tbh I don't think they meant it since I didn't pass.
No, I think the Linux Foundation is willing to say nice things about Microsoft to keep those sweet funds coming. If you want to buy someone, you pay money.
There are still shops that use cobol, but no one starts new projects in that language, and people have been migrating away from it for a while. The pay for that skill is low, and you'd do better learning APL.
Fortran used to get a lot of use in the math areas, but they've all switched to python (numpy), R, or matlab. Combined, these do everything fortran did but better.
It's important to remember that there are an order of magnitude more programmers now than there were in the days cobol was popular, and they write a lot of code. Java is the new COBOL, and has been for 15 years.
Slashdot Mirror
BDUF / Waterfall is way worse than Agile.
Have you ever done BDUF or Waterfall?
What rules are you talking about? The agile manifesto specifically says, "we value Individuals and interactions over processes and tools." It sounds like you are too focused on rules, and have lost sight of what Agile truly is.
God
on one end of the spectrum you can formally spec out the entire system and wait a lifetime to get something that doesnt do what you want, using the waterfall model, due to too much involvement on the other end of the spectrum you can describe what you want to the developers over a beer in the pub and wait a lifetime to get something that doesn't do what you want because of a lack of involvement scrum/agile should be the lesser of both evils, 'hey, this week can you create the signup and onboarding flow, and login and forgot password please' where you break the big picture down in to meaningful deliverables you can iterate on to demonstrate constant progress to the stakeholders.
This can be done merely by having shorter release cycles. No need to do all of scrum.
if it devolves to 'working harder' that means the entire team is unable to make correct time estimates or worse, is ok with being unable to make realistic time estimates.
That indeed is a symptom of the problem.
Funny how so many people claim systemd is a lousy architecture to build upon, yet never provide any evidence to support those claims
Nah, I did a fairly long analysis of the strengths and weaknesses of systemd in my journal. If you disagree, go ahead and tell me: it will increase my knowledge.
Log message problems can be fixed (maybe by a different team, though), if that were the worst thing, it wouldn't be a problem. The problem is systemd is crappy architecture, and you don't want to build stuff on top of crappy architecture to get it embedded deeply within the system, you want to keep it flexible and replaceable. That's why this project is good even if you never use it, because it will improve the quality of the software you do use. And those people who do like systemd can use it.
I'm waiting for Devuan EBCDIC personally.
Yes, people gave FB their info. No, they did not willingly give that to Russia to fuck with out system and install a traitor.
Next time someone says, "I don't care about my privacy," give them a cookie.
ok, so you are describing a disfunctional organization. Not the kind of place I like to work.
What is the point of a daily meeting? It's not for status updates (otherwise you wouldn't need a tracker). It's to make sure programmers are working. That's why.
Most of it is uncreative. We're just doing websites that are slightly different than what's been done before.
The stuff we're programming in Silicon Valley is closer to what the village idiot does than what Einstein did. It's all a bunch of crappy workflow software.
Oh yeah, you're right. I completely misread your post. Carry on and trash my previous comment.
Trustworthiness and skill are orthogonal.
ok, you completely misunderstood or you are trolling. Examples.
1)A person doesn't know how to write Javascript or CSS. Can you trust this person to finish the frontend featureset by next week? No, you can't.
2)A person doesn't have good estimation skills. Can you trust this person to estimate when they will finish? No, you can't. Another example:
3)A person has finished their work within the estimate every sprint for the last six months. Can you trust this person to correctly estimate when they will finish? Yes, you can.
So.... What is the difference between the second and third example? One of them has skill in estimation, and the other doesn't. That's it. So teach that person how to estimate. There are ways to do that.
Beyond the headline, here's what he says:
1) The team itself should choose the process because imposing process company-wide by business execs is bullshit. If you have a consultant come in and impose a method, that's reverse of what should happen.
2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)
3) All you need are three principles and those are, "release code often" "keep your code clean," and "push back against managers imaginations" by focusing on reality: what state the code is in now.
Again he reiterates, if process is imposed from above instead of chosen by the team, things will go wrong. He's kind of echoing Fred Brooks here, who said, "The teams need a process, but they choose it on their own."
Agile (more specifically, scrum and derivatives) is a tool managers use to keep programmers on task, and to get them to work harder. In that way, it begins from a position of lack of trust, you use it because you don't trust the developers to take care of things.
Ultimately that is the opposite of Agile, which says, "We value individuals and interactions over processes and people." If you don't trust your developers, the focus should be on improving the skill of your developers so you can trust them. The best agile methods focus on improving the soft skills of the programmers, rather then beating them down or 'controlling' them with process.
There is, though. Right there at the top it says, "We value individuals and interactions over processes and tools." Is Agile a process? Primarily it's not. Ask your consultant what they are doing to value individuals over processes. Watch the blank look of fear, followed by a stream of BS coming out of their mouth.
Coffeescript is dead but TypeScript is increasing in popularity.
Being strongly typed makes a language bad for large applications? No, being strongly typed is what keeps it from turning into an impossibly incoherent mess like large JavaScript programs.
It took me a long time to understand why Java is popular, because I couldn't really see a use for it. Finally I realized it fits one niche really, really well: you can put a bunch of low-skill developers to work in Java, and they won't mess the code base up beyond ability to work in it. Oh, they will make it really ugly, but those same developers in C would end up with something completely broken and unsalvagable.
Java is the COBOL of our era.
No, it's fun! I actually tried APL in a job interview once. They said, "Use any language you want." "Really?? OK." tbh I don't think they meant it since I didn't pass.
No, I think the Linux Foundation is willing to say nice things about Microsoft to keep those sweet funds coming. If you want to buy someone, you pay money.
Microsoft is a Platinum member of the Linux Foundation.
Most used is probably cobal,
There are still shops that use cobol, but no one starts new projects in that language, and people have been migrating away from it for a while. The pay for that skill is low, and you'd do better learning APL.
Fortran used to get a lot of use in the math areas, but they've all switched to python (numpy), R, or matlab. Combined, these do everything fortran did but better.
It's important to remember that there are an order of magnitude more programmers now than there were in the days cobol was popular, and they write a lot of code. Java is the new COBOL, and has been for 15 years.
they "trust" me. dumb fucks
It can't be remembered enough that Zuckerburg actually said that.