May 16, 2012 at 10:25 am
Capt. Sigerson (5/16/2012)
Lynn Pettis (5/16/2012)
The problem I have seen is the lack of the Business Analyst and Database Analyst/Architect working on the project in this fashion, at least on the projects I have been involved in so far.
I think this is a common problem. Very few managers have the technical skill or aptitude to really visualize a complete solution top to bottom, but they see developers turn out miracles every day. They conclude that preliminary analysis is a waste of their time and a design on a cocktail napkin is all we need. It ends up wasting the developers' time because you know they'll be back inevitably at testing time with a raft of additional changes they'd forgotten to mention because they cut off the analysis period too early.
The illusion of speed, where skipping some important steps, sometimes creates a lot of extra activity.
If only those above could see this for what it is.
You can't (and shouldn't) plan something to death, but if you don't know where you're going, it might be hard to get there.
May 16, 2012 at 10:28 am
Lisa Slater Nicholls (5/16/2012)
Capt. Sigerson (5/16/2012)
Lisa, how about expanding your thoughts on the two types into a larger article?Well, as all of us oldsters probably know, the concept isn't original with me. One of the advantages of experience is having read Dr. Dobbs etc for a long time <s>. (If memory serves... yep, Kent Beck's writings were probably the first time I heard the terms although I don't know that he originated them. See http://www.drdobbs.com/mobile/184409176 .)
Thank you for the link to Kent Beck's article. It has a lot of interesting concepts.
Sigerson
"No pressure, no diamonds." - Thomas Carlyle
May 16, 2012 at 10:28 am
Craig-315134 (5/16/2012)
Like you, I come here to learn (although the occasional pontification is enjoyable, too). I hope you did not take offence at my words, as I simply didn't understand your division between - what were they? Abstractors and emulators? Homogenators and emulsifiers? Drat, I can't remember now!
Craig <rofl>... I didn't take offense at all... one of the prerequisites to being a professional author, especially in tech writing, is to assume that if you didn't get your point across it's your fault. You need to rewrite, and probably to simplify.
Anyway, as I said above, it's not my concept and I was shortcutting into what I draw *out* of the concept, rather than explaining it, because it's pretty standard. You can read the Kent Beck article I mentioned (http://www.drdobbs.com/mobile/184409176), but basically the idea is:
Some software developers (the abstractors) are really good at abstracting the common parts of software problems and creating reusable tools to deal with them. Others (the elaborators) use those tools, delighting end-users with the results.
It's like being left- or right- handed. Although I believe everybody has some ability to do both, most people aren't "ambidextrous"; they're much stronger doing one type of activity than the other.
This is certainly not the only way to look at software developer personalities. Another one I find useful is Guy Kawasaki's (the Apple evangelist). He said something like this (from memory, can't find on line anywhere):
Carl Jung divided humans into a number of personality archetypes. People are not evenly distributed within those archetypes. People who make good software developers are usually described by one of two of these archetypes, which happen to be ones that are quite rare in the total population.
At this point GK had a marvelous metaphor drawn from the way people play computer games. Developers played these games when they were just words on a page, "other" people didn't play them until they got graphics. Why not? I'm going to screw up paraphrasing it so I will have to leave out that part. Anyway, returning to GK's argument:
It follows that most software developers should not be designing UI/UX for everybody else. They need to be complemented by a second group, who have a different way of looking at the world.
The interesting thing here is that Kawasaki was actually performing as an meta-abstractor for the whole process of development. He was recognizing a pattern, and giving it a shape.
Other people still had to come along and elaborate on this, didn't they? They had to work out ways for the different participants to interact successfully in the development process. We're still trying to work this one out. MS tried recently to tool-out the problem with Expression, but I don't think it was even close.
>L<
May 16, 2012 at 10:31 am
Grady Booch, now there a name I haven't heard in awhile. The "Einstein of IBM"(kind of looks like him too) he came up with UML didn't he?:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
May 16, 2012 at 10:37 am
Some software developers (the abstractors) are really good at abstracting the common parts of software problems and creating reusable tools to deal with them. Others (the elaborators) use those tools, delighting end-users with the results.
Got it! We used to call them 'tool makers' and 'tool users'.
Thanks for the clarification. I appreciate your persistence in educating me.
May 16, 2012 at 10:46 am
Craig-315134 (5/16/2012)
I've discovered that, just as there are ideologues in politics, there are ideologues in methodologies as well.
Oh definitely. First came the high priests of the mainframe... and then the Tower of Babel... and sects and tongues unnumbered. <g>
Sometimes us practical sorts are shouted down or out of the conversation, and expected to make an unwieldy methodology perform to some unreasonable standard.
If and when this happens to you, it helps to remember that they're generally scared. People who put their faith (there's no other word for it) in a methodology, or who practice rule-based management, often realize that they don't know anything at all, although they hope *you* don't realize it. They need other people to paint by numbers because it's all they can understand.
If you can remember that, you can usually play to it, without losing your ability to GSD. (Get, er, Stuff Done).
And now, having quoted some real software luminaries in this thread, I'll devolve and quote myself (http://spacefold.com/lisa/post/2007/08/12/Language-Arts.aspx)
The right tool to use is the one that most efficiently and most excellently provides the result I want, period.
Whether the language is dynamic or not is irrelevant if I don't happen to need it in what I'm doing (although it is often an extremely useful feature). Whether overloads and/or multi-inheritance etc etc etc are available are not pertinent to my decision for a project-at-hand in any abstract way, either. They're not articles in a credo.
>L<
May 16, 2012 at 10:48 am
TravisDBA (5/16/2012)
Grady Booch, now there a name I haven't heard in awhile. The "Einstein of IBM"(kind of looks like him too) he came up with UML didn't he?:-D
Yes along with somebody else -- Iverson? I'm not going to google it <g>.
>L<
May 16, 2012 at 10:48 am
Lynn Pettis (5/16/2012)
Before you can do Agile or Scrum type development, there still needs to be a period of time up front to develop the system requirements. There needs to be a consensus on what the system should do so that the features that need to be designed and implemented can be identified and prioritized. Not all of them need to be full fleshed out initially, but the first core functions should be. A business analyst and databaae Analyst/Architect should then been fleshing out the more detailed requirements for the first 3 or 4 sprints while the project team works on Sprint 0, getting the development and test environments setup and ready. The Business Analyst and Database Analyst/Architect then continue to work forward fleshing out the additional requirements for each future Sprint, staying 3 or 4 Sprints ahead of the development team, as well as working with them at the beginning of each Sprint during the Sprint Planning session helping to make sure that the development team understands the requirements of each task they agree to work on for that sprint.The problem I have seen is the lack of the Business Analyst and Database Analyst/Architect working on the project in this fashion, at least on the projects I have been involved in so far.
Exactly. I have the sense that today software nerds do everything they can think of, even coining some terms like "scrum" and "agile", it seems to avoid doing the very things you just elaborated on Lynn.
Ignorance is bliss I suppose, but I laugh when hear management say things like "we need to get this to market and don't have the time or the manpower to spend on design or documentation..." In every case I have seen like this far more man-hours have been spent after the fact (to fix bugs on slap more hacks onto it to make it work) than would have been spent had the some extra time been allocated up front for a specification and design phase.
Sigh...
The probability of survival is inversely proportional to the angle of arrival.
May 16, 2012 at 10:50 am
Yep, a real old guy that is still around.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
May 16, 2012 at 11:00 am
Scrums are silly IMHO. People with health, foot or leg issues, or disabilites for that matter, should not be be told or forced to stand in scrum meetings. That's just silly in my opinion.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
May 16, 2012 at 11:08 am
TravisDBA (5/16/2012)
Scrums are silly IMHO. People with health, foot or leg issues, or disabilites for that matter, should not be be told or forced to stand in scrum meetings. That's just silly in my opinion.:-D
I agree, and if that is the case we didn't force them to stand. The real purpose of standing is to help force the scrum to be short. I know I wouldn't want to stand in a meeting for an hour or more.
If you have a good team and they can keep everything short, sweet, on topic without having to stand, then don't. The tendency is to to eloborate when you are sitting comfortably.
A good Scrum Master could probably help keep things short.
May 16, 2012 at 11:16 am
Lynn Pettis (5/16/2012)
TravisDBA (5/16/2012)
Scrums are silly IMHO. People with health, foot or leg issues, or disabilites for that matter, should not be be told or forced to stand in scrum meetings. That's just silly in my opinion.:-DI agree, and if that is the case we didn't force them to stand. The real purpose of standing is to help force the scrum to be short. I know I wouldn't want to stand in a meeting for an hour or more.
If you have a good team and they can keep everything short, sweet, on topic without having to stand, then don't. The tendency is to to eloborate when you are sitting comfortably.
A good Scrum Master could probably help keep things short.
In the scrums I have been in that doesn't stop healthy people from running on at the mouth for long periods anyway. Meanwhile, people with disabilities and health issues are made very uncomfortable, even if the meeting is only 10 minutes in length. And what about team members in wheelchairs? How is that handled in a scrum meeting? Are they discriminated against because they can't stand up? The whole idea is just silly in my opinion. The whole Agile approach idea seems to have been hatched by young people without any consideration for the elderly, ill, or disabled.. Were IT people, we are not 20 year olds on a rugby team. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
May 16, 2012 at 11:24 am
TravisDBA (5/16/2012)
Lynn Pettis (5/16/2012)
TravisDBA (5/16/2012)
Scrums are silly IMHO. People with health, foot or leg issues, or disabilites for that matter, should not be be told or forced to stand in scrum meetings. That's just silly in my opinion.:-DI agree, and if that is the case we didn't force them to stand. The real purpose of standing is to help force the scrum to be short. I know I wouldn't want to stand in a meeting for an hour or more.
If you have a good team and they can keep everything short, sweet, on topic without having to stand, then don't. The tendency is to to eloborate when you are sitting comfortably.
A good Scrum Master could probably help keep things short.
In the scrums I have been in that doesn't stop healthy people from running on at the mouth for long periods anyway. Meanwhile, people with disabilities and health issues are made very uncomfortable, even if the meeting is only 10 minutes in length. And what about team members in wheelchairs? How is that handled in a scrum meeting? Are they discriminated against because they can't stand up? The whole idea is just silly in my opinion.:-D
Glad you mentioned wheelchairs. We had a team member at a previous company who was in a wheelchair, double amputee, and no he wasn't discriminated against. Common sense does exist sometimes, quite amazing.
If people oar running on at the mouth, that means the Scrum Master isn't doing his/her job. Of course, it is worse if it is the Scrum Master running of at the mouth. Then it is up to the team to cut him/her off and get the meeting back on topic. Just three things: What I did yesterday, what problems did I encounter that I need help with (don't solve them here), and what am I going to be working on today. Should be short, sweet, and simple.
May 16, 2012 at 11:27 am
If people oar running on at the mouth, that means the Scrum Master isn't doing his/her job. Of course, it is worse if it is the Scrum Master running of at the mouth. Then it is up to the team to cut him/her off and get the meeting back on topic.
Agreed, but in real-world practice that doesn't always happen. It's a silly idea in the first place, that's the common sense of it 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
May 16, 2012 at 2:37 pm
Craig-315134 (5/16/2012)
What we always need to remember is that it's the practitioners, not the methodology *or* the patterns, that are going to make the critical difference between success or failure.Very well put indeed.
Completely agree. It isn't the system, but the people.
So hire carefully.
Viewing 15 posts - 76 through 90 (of 94 total)
You must be logged in to reply to this topic. Login to reply