People are his problem, not process. You can take any methodology or process and twist it to your own ends. Along the very same lines, I'm not a big fan of the metrics surrounding process. Like all statistics, it can support whatever story you want to tell and can't replace the insight of someone who knows what's really going on.
The core problem is that coordinating people is positioned as "moving up", so you get people in those positions that aren't very good at it. Programming is a very different skill than coordinating people. To me, managing just another skill set and the manager should be treated like just another team member. And of course, the other core problem is that most people aren't very mature.:-)
I see a lot of negative comments here about Agile, and I think it's because those saying it just want to be heads-down coders. Or worse, they don't want to tell anyone what they're doing in order to keep control over it. What Agile does well is to get the business people involved in the project in a way they can understand. Instead of a poorly written requirements document, it's an interconnected web of sticky notes. They can SEE the complexity. If a project is late, it's no surprise because they've seen the entire journey.
On the contrary. Religious people are often those most taken by fear, thus all the praying. It's no wonder then, that they would also be afraid of death.
I always start with the database, if it has one. Once I understand what the application needs to leave behind, I have a much better understanding of what it could do.
Another trick is running a tool to list out every code file sorted by line count. Sounds strange, but I get to see where all the action is.:-)
The last time I had to do this was with a Java framework that used Spring heavily. If you're not familiar, basically, the code is woven together using XML files. Imagine sorting through that and figuring out how it works! This and the developers abstracted everything to the Nth degree. Arg! I did two things:
(1) Try throwing debug lines in everywhere. Have them store a stack trace into a file somewhere. That's the quick and dirty way of seeing who's calling who. Once you start to see what code lies on top of other code, you can stop with all the debugging and tool use and just read the code for itself.
(2) I was able to use jdb (the command-line java debugger Sun releases) to report every method call from every thread. That's very similar to what I think etrace does, another app someone's already mentioned on this thread. Basically, it was a complete record of everything the application did. It happened to be useful in my case, but of course, it produces a document too huge to consume easily. There are ways of setting certain calls to "not-important" and reducing the size significantly.
I had a similar experience. The teacher that turned me on to writing was an instructor I had in colloge. He'd ask everyone to pick their best sentence from that week's assignment. He'd ask us to write it on the board, then he and the class would tear it apart and completely rewrite it. It really got us thinking about what and how we were writing. Do we need this word/phrase? What word/phrase would be stronger here? etc.
And I'm still learning the lesson of writing to your audience. It's not "writing" to them, it's "understanding" them that's difficult. Especially for engineers writing about subjects they're familiar with and that their audience (unbeknownst to them) could never understand it in the way they do. I think journalism is a good teacher here. Put the who/what/where/when/why in the first few sentances. It doesn't matter who you are or what you're reading, there's a chance you're going to skim. Best to write for skimmers. I've started writing even small subsections with little bolded titles to catch those who are going to spend five seconds in that area. (It also helps people find what they're looking for.) And I even make seperate versions of the same explanation with titles like "one sentence", "one paragraph", "half page" to describe how detailed I'm getting. After all, especially in technology, you'll never know the abilities, understanding, or interest of those who pick up your documents.
Sorry if this is redundant, but the best way to go is big, close-up pictures of things. Then at least they'll finally know what they've been talking about. Also compare computers to humans, like short term memory=RAM, etc.
We live in a legacy world. It's about time we work that realization into the technology we choose to use.
Most programming languages (and their many versions) are quite similar, but it takes skilled workers and time to rewrite the code. If we could set up XML standards for it, then we could convert code to and from these standards. Not only do we make the rewrite easier, but we preserve most, if not all, the effort put in by the original programmer.
Slashdot Mirror
People are his problem, not process. You can take any methodology or process and twist it to your own ends. Along the very same lines, I'm not a big fan of the metrics surrounding process. Like all statistics, it can support whatever story you want to tell and can't replace the insight of someone who knows what's really going on.
:-)
The core problem is that coordinating people is positioned as "moving up", so you get people in those positions that aren't very good at it. Programming is a very different skill than coordinating people. To me, managing just another skill set and the manager should be treated like just another team member. And of course, the other core problem is that most people aren't very mature.
I see a lot of negative comments here about Agile, and I think it's because those saying it just want to be heads-down coders. Or worse, they don't want to tell anyone what they're doing in order to keep control over it. What Agile does well is to get the business people involved in the project in a way they can understand. Instead of a poorly written requirements document, it's an interconnected web of sticky notes. They can SEE the complexity. If a project is late, it's no surprise because they've seen the entire journey.
On the contrary. Religious people are often those most taken by fear, thus all the praying. It's no wonder then, that they would also be afraid of death.
An old IBM man once told me that they did extensive experiments with colors. They found that dark blue text on light yellow was the best.
I always start with the database, if it has one. Once I understand what the application needs to leave behind, I have a much better understanding of what it could do.
Another trick is running a tool to list out every code file sorted by line count. Sounds strange, but I get to see where all the action is. :-)
The last time I had to do this was with a Java framework that used Spring heavily. If you're not familiar, basically, the code is woven together using XML files. Imagine sorting through that and figuring out how it works! This and the developers abstracted everything to the Nth degree. Arg! I did two things: (1) Try throwing debug lines in everywhere. Have them store a stack trace into a file somewhere. That's the quick and dirty way of seeing who's calling who. Once you start to see what code lies on top of other code, you can stop with all the debugging and tool use and just read the code for itself. (2) I was able to use jdb (the command-line java debugger Sun releases) to report every method call from every thread. That's very similar to what I think etrace does, another app someone's already mentioned on this thread. Basically, it was a complete record of everything the application did. It happened to be useful in my case, but of course, it produces a document too huge to consume easily. There are ways of setting certain calls to "not-important" and reducing the size significantly.
Good luck!
I had a similar experience. The teacher that turned me on to writing was an instructor I had in colloge. He'd ask everyone to pick their best sentence from that week's assignment. He'd ask us to write it on the board, then he and the class would tear it apart and completely rewrite it. It really got us thinking about what and how we were writing. Do we need this word/phrase? What word/phrase would be stronger here? etc. And I'm still learning the lesson of writing to your audience. It's not "writing" to them, it's "understanding" them that's difficult. Especially for engineers writing about subjects they're familiar with and that their audience (unbeknownst to them) could never understand it in the way they do. I think journalism is a good teacher here. Put the who/what/where/when/why in the first few sentances. It doesn't matter who you are or what you're reading, there's a chance you're going to skim. Best to write for skimmers. I've started writing even small subsections with little bolded titles to catch those who are going to spend five seconds in that area. (It also helps people find what they're looking for.) And I even make seperate versions of the same explanation with titles like "one sentence", "one paragraph", "half page" to describe how detailed I'm getting. After all, especially in technology, you'll never know the abilities, understanding, or interest of those who pick up your documents.
Sorry if this is redundant, but the best way to go is big, close-up pictures of things. Then at least they'll finally know what they've been talking about. Also compare computers to humans, like short term memory=RAM, etc.
Ian.C.Rae@gmail.com
We live in a legacy world. It's about time we work that realization into the technology we choose to use. Most programming languages (and their many versions) are quite similar, but it takes skilled workers and time to rewrite the code. If we could set up XML standards for it, then we could convert code to and from these standards. Not only do we make the rewrite easier, but we preserve most, if not all, the effort put in by the original programmer.