[OCP 21 book] | [OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Junilu Lacar wrote:That's another misconception. Documentation is not taboo. Documentation that people spend a lot of time on that hardly anyone reads is strongly discouraged..
Junilu Lacar wrote: I suggest the book "Software Architecture for Developers" by Simon Brown.
Jeanne Boyarsky wrote:Jan,
Just to be clear, i"m not suggesting you criticize "Scrum" or whatever they are calling it at the retrospective. I was suggesting small improvements to make things better.
Tim Holloway wrote:and I loathe people and organizations that use a Good Thing as a blunt instrument to hammer down the peons. I've also been known to make sarcastic remarks about anything that simply provides an excuse to bring in overpriced software and/or overpriced consultants.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Jan de Boer wrote:
Junilu Lacar wrote:That's another misconception. Documentation is not taboo. Documentation that people spend a lot of time on that hardly anyone reads is strongly discouraged..
And who decides what is hardly read? There are for example very useful examples and exercises in my project. I have used them, I have read them. But since the scrum zealots here think programmers don't read anyway, they are not maintained anymore from now on. We have a sort of attitude like, reading is for nerds. If you read you are unpractical, uncommunicative, unscrummy. Noise is cool. What documentation was not read by whom? It was read by me! The only documents pile not being read was when I was working in PL1 on a mainframe for a bank a quarter of a century ago. Now that was a real waterfall project. But real waterfall projects, in the sence the scrum zealots describe it, hardly existed anymore before scrum appeared. Scrum did not solve the waterfall documentation overload problem. That waterfall documentation overload has become a sort of 'urban legend' (if that is the right English word to describe it).
Jan de Boer wrote:
Junilu Lacar wrote: I suggest the book "Software Architecture for Developers" by Simon Brown.
By the way this is another reason for me to dislike scrum. This attitude, if you do not like, it is because you have not understood it.
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Winston Gutkowski wrote:
Tim Holloway wrote:and I loathe people and organizations that use a Good Thing as a blunt instrument to hammer down the peons. I've also been known to make sarcastic remarks about anything that simply provides an excuse to bring in overpriced software and/or overpriced consultants.
And it's the same with methodologies: I suspect very strongly that ANY reasonable one will be successful, providing a company is willing to spend the time (ten years at the very least, IMO) and money to develop expertise and familiarity in it. Unfortunately, far too many of them seem more interested in the latest snake-oil acronym.
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Junilu Lacar wrote:
Jan de Boer wrote: By the way this is another reason for me to dislike scrum. This attitude, if you do not like, it is because you have not understood it.
All I'm saying is that your generalization of specific problems, while they are becoming quite common, is not because of the ideas behind Scrum or Agile.
Jan de Boer wrote:
Scrum is like islam! If you do not like it, you have not understood it and you should read the book. If something bad comes out of it, it is not really islam/scrum. And and now: if you attack it too vigourisly, you're a generalzing bigot!
:-)
Junilu Lacar wrote:
The SA4D book is not about Scrum. It's a common sense approach to architecture (it recommends that project architects should also write code so they can see their ideas materialize as running software) and project supplemental documentation. I dont recall any part of the book even mentioning Scrum.
Jan de Boer wrote:
Junilu Lacar wrote:
The SA4D book is not about Scrum. It's a common sense approach to architecture (it recommends that project architects should also write code so they can see their ideas materialize as running software) and project supplemental documentation. I dont recall any part of the book even mentioning Scrum.
Well I have read this one: James Coplien Lean Architecture. It talks about the importance of architecture in the scrum process. That improving the architecture is a constant part of the scrum process. That the architecture role should not be a task of a sole person but the responsibility of the whole team. That there should be constant refacturing. Is it something like that?
Jan de Boer wrote:Well, the more I read about scrum, the more I am getting to hate it. Sorry! I read Extreme Programming from Kent Beck, ten horseshoes here. I was so irritated by it, people in the train got scared off me! (I read the book in the train, and at some pages made indecent gestures.)
Jan de Boer wrote:I know all that stuff! I know what the values of Agile and Extreme programming are. I know the ideas behind it.
Junilu Lacar wrote:some of which I agree, some of which I don't particularly agree.
Jan de Boer wrote:
Junilu Lacar wrote:some of which I agree, some of which I don't particularly agree.
Cannot I do the same with scrum? It is exactly the 'religious' part that gets on my nerves. Like it is a revelation, and a revolution. The if you do not like it, there is something wrong with you. And in your last posts you are doing that thing. That just raises an aversion.
One last thing to say. Scrum generalizes that people are all the same. I for example like to read documentation as a backup. I do not think personal contact is always the best way to communicate. Especially when it then comes down to numerous interuptions of your work. Please send me an email instead of constantly interupting me, because this is team work. Scrum makes me think of the teacher in Pink Floyds the Wall making humdrum of all the pupils. Do you know that movie? I saw it when I was the school going age. But it more applied to professional life after school then actually school itself.
Jan de Boer wrote:Sorry but, if not you, scrum constantly makes me feel there is something wrong with me. That is the whole point.
O'Sensei Morihei Ueshiba wrote:Opponents confront us continually, but actually there is no opponent there. Enter deeply into an attack and neutralize it as you draw that misdirected force into your own sphere.
It says, all programmers hate to read, all programmers hate to write documentation.
And I like to have things written down.
Jan de Boer wrote:
In the Kent book there was interview. If people do not want to pair program, fire them.
Jan de Boer wrote:
Also it said, good programmers like to be in a noisy room, because then they communicate and make progress.
And again I cannot concentrate with too much noise.
Jan de Boer wrote:
Also it said, if there is no noise in a scrum team, there is something wrong with the team.
Junilu Lacar wrote:So, when you say the waterfall documentation overload has become an "urban legend" I have to wonder, is it just that bad at the places that I know these things have and continue to happen or is Winston working in a place filled with enlightened waterfallers?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Sorry to disappoint you but I'm totally with you on this one, W, my friend. Besides, it's Friday and I like to end my week on an upbeat noteWinston Gutkowski wrote:
That said, I HAVE worked in places that made waterfall change-control work pretty well. Why? Because they had years of experience using it.
Bring it on Junilu.![]()
They don't tell you what they're bad at
Junilu Lacar wrote:I agree, they generally don't tell you what they're bad at but a good Agile coach will tell you that more than anything else, Agile reveals to you what you're bad at.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Oh, and if I have people that don't work well with Agile, then it's their fault, so I don't have to feel bad about firing them....
If you work for a man in heaven's name,
work for him, speak well of him,
and stand by the institution which he represents.
...
If you must growl, condemn, and eternally find fault,
Why, resign your position!
And when you're on the outside,
Damn to your heart's content.
But as long as you are part of the institution,
Do not condemn it.
For if you do,
The first high wind that comes along
Will blow you away
And probably you'll never know why.
Winston Gutkowski wrote:
Oh, and if I have people that don't work well with Agile, then it's their fault, so I don't have to feel bad about firing them....
Junilu Lacar wrote:All it takes is an awareness that you suck, a determination to get better, and the perseverance and dedication to work harder at getting better and powering through that "suck zone". To me, that makes all the difference in the world whether you end up a happy camper or someone morosely looking in from the outside.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
So: if you use Agile, and your project collapses in a steaming heap, it's your fault; not Agile's.
Winston Gutkowski wrote:
The test of how good Agile or Scrum (or any other methodology) is, is going to be in how long your company uses it. And if it passes the 5 year test, then it may be worth committing to memory; otherwise: keep the good bits and forget the rest.
There are only two generalisms I can attest to in my career about good programmers:
1. They're intelligent.
2. They like beer.
and I'd like to think that I qualify on both counts.![]()
Winston Gutkowski wrote:
The Dunning-Kruger effect refuses to allow me to rest on my laurels, nor indeed concede that I might be an expert an anything; despite the fact that I have 30 years of professional experience - probably twice as much as most of the high-price bods that companies I've worked for pay to tell me what I'm doing wrong.
Junilu Lacar wrote:If you join the Military, there is a certain way you do things. If you break the rules, you're out.
If you're playing a game, and you flout the rules of the game, you're going to get ejected.
If you live in a society and you don't abide by the mores and social conventions, you can get in trouble. Sometimes, depending on the society, you can get into serious trouble.
If you want to be part of an Agile team, then it's natural to have to abide by the rules and conventions of Agile. How is that unreasonable?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Junilu Lacar wrote:If you want to be part of an Agile team, then it's natural to have to abide by the rules and conventions of Agile. How is that unreasonable?
Because I didn't ask to "be part of an Agile team". Somebody - and probably someone with very little experience of programming (if any) - imposed that on me.
Junilu Lacar wrote:There's a common thing that the best senseis I've met in Aikido dojos do when they instruct and guide students. They always say "Good, good! But here's how you can do this better." It's not that they're trying to be condescending either. They're right. Whatever seems to work for the student is really fine. But if the student wants to learn at improve their Aikido, they also need to open their mind and observe what sensei shows them.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Thanks tiny ad, for helping me escape the terrible comfort of this chair.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|