Article pre-publishing comments
-
Hi, I prepared an article about Agile Programming and Refactoring for CP, it still needs some scrubbing (and proof-reading), but I figure it would be nice if someone else already has a look at it, and give some comments. it's here: clickety[^] I'm not very happy yet, I feel it's a bit too long, and not "focused" enough (I feel I'm trying to cover to much). I'm especially unsure if tje "real life example" makes any sense at all... Thanks in advance Peter
As James Bond in "die another day", Pierce Brosnan features traits handy in the dawning millenium. He fights without hesitation in a bewildering environment, trusts his high-tech-gadgets, and rather falls for beauty than pondering the political absurdities around him. [sighist]
-
Hi, I prepared an article about Agile Programming and Refactoring for CP, it still needs some scrubbing (and proof-reading), but I figure it would be nice if someone else already has a look at it, and give some comments. it's here: clickety[^] I'm not very happy yet, I feel it's a bit too long, and not "focused" enough (I feel I'm trying to cover to much). I'm especially unsure if tje "real life example" makes any sense at all... Thanks in advance Peter
As James Bond in "die another day", Pierce Brosnan features traits handy in the dawning millenium. He fights without hesitation in a bewildering environment, trusts his high-tech-gadgets, and rather falls for beauty than pondering the political absurdities around him. [sighist]
[edit]Oops, sorry about that, I just read your bio Hi! [/edit], Barring minor spelling and grammatical errors, I thought your article was excellent. I was really sucked in by your introduction, and found it quite interesting that [edit]both a designed [edit]and a non-designed effort end up in the same place. Your content is quite good and you get your ideas across well and in a manner that I found entertaining. I don't think it's too long, and I thought it was sufficiently focused. I've had a lot of experiences that fit exactly into what you described, and I've had a lot of successes where the processes that I've followed turned out to be exactly those described in Agile Programming. In fact, I'm even a member of the Agile Alliance! The thing is, I haven't found anything in Agile Programming that tells you HOW to design better software, from a software design perspective. It says lots of wonderful things about the development process, but not the actual architectural design of the software. Instead, it seems that AP tries to fit in with existing design practices. This is just plain wrong, in my opinion. While each design practice has some merits, they all have major flaws that are propagated by frameworks like MFC and .NET and the architectures that Microsoft tries to force upon people. This is why I'm writing a series of articles on this: http://www.codeproject.com/useritems/AAL-1.asp[^] As far as I'm concerned, the only way the principles of AP can succeed is if we change how software is architected. And as far as refactoring goes, it's an excellent technique, but the real effort should be put into preventing code from being written that ultimately needs refactoring. OK, every piece of code could stand for some refactoring--I just think this approach ends up being used for major surgery where prevention would have been better to begin with. At the conclusion of your article, you state The best selling point is success.. I have "sold" (not in the monetary sense, but in the adoption sense) to management my AAL concept to several different companies and to my team members, because it does work. In other words, I've combined using the right software architecting techniques AND Agile Programming techniques for success. They are both required. If that gives you any food for thought, let me know! Marc
-
Hi, I prepared an article about Agile Programming and Refactoring for CP, it still needs some scrubbing (and proof-reading), but I figure it would be nice if someone else already has a look at it, and give some comments. it's here: clickety[^] I'm not very happy yet, I feel it's a bit too long, and not "focused" enough (I feel I'm trying to cover to much). I'm especially unsure if tje "real life example" makes any sense at all... Thanks in advance Peter
As James Bond in "die another day", Pierce Brosnan features traits handy in the dawning millenium. He fights without hesitation in a bewildering environment, trusts his high-tech-gadgets, and rather falls for beauty than pondering the political absurdities around him. [sighist]
I read your article and I think it is written well. I would suggest that you include an overview where you list your 5 points (the ones in blue) by themselves before the main body of the article. I don't think it is too long. One thing that I would suggest covering is how to plan for refactoring. What I mean is to tell how to develop code that is intended to be refactored. Sometimes it is necessary to "find" a solution before you can code it properly. Unfortunantely, many times this "experimental" code becomes part of production systems. Planning for refactoring at this level is important because it recognizes the reality of the likelihood of the code finding its way into production systems and it makes the refactoring more productive. If you plan for refactoring you will not leave off application-critical steps (like validating inputs, checking errors, catching exceptions, etc), instead you will keep your design simple but your code well written. One questionable aspect of AP techniques is that it focuses too heavily on ultra small time-frames and tends to make a developer rely on the compiler too heavily. I find that being able to focus on a code related problem as a whole problem, not just as a component of the problem is often more effecient and ultimately more productive than time-slicing the problem into smaller compoenents. This does not necessarily go against AP, but on the surface seems to. Also, one of the strengths most developers have is the ability to keep lots of "state" info in their heads at a time as long as it is focused. AP often tends to limit the amount of focus a developer uses by time-slicing everything and I believe reduces the total amount of "state" a developer can handle because while I can remeber 7 related things at a time, I can only remember 4 unrelated things at a time. All-in-all, a good article.
-
[edit]Oops, sorry about that, I just read your bio Hi! [/edit], Barring minor spelling and grammatical errors, I thought your article was excellent. I was really sucked in by your introduction, and found it quite interesting that [edit]both a designed [edit]and a non-designed effort end up in the same place. Your content is quite good and you get your ideas across well and in a manner that I found entertaining. I don't think it's too long, and I thought it was sufficiently focused. I've had a lot of experiences that fit exactly into what you described, and I've had a lot of successes where the processes that I've followed turned out to be exactly those described in Agile Programming. In fact, I'm even a member of the Agile Alliance! The thing is, I haven't found anything in Agile Programming that tells you HOW to design better software, from a software design perspective. It says lots of wonderful things about the development process, but not the actual architectural design of the software. Instead, it seems that AP tries to fit in with existing design practices. This is just plain wrong, in my opinion. While each design practice has some merits, they all have major flaws that are propagated by frameworks like MFC and .NET and the architectures that Microsoft tries to force upon people. This is why I'm writing a series of articles on this: http://www.codeproject.com/useritems/AAL-1.asp[^] As far as I'm concerned, the only way the principles of AP can succeed is if we change how software is architected. And as far as refactoring goes, it's an excellent technique, but the real effort should be put into preventing code from being written that ultimately needs refactoring. OK, every piece of code could stand for some refactoring--I just think this approach ends up being used for major surgery where prevention would have been better to begin with. At the conclusion of your article, you state The best selling point is success.. I have "sold" (not in the monetary sense, but in the adoption sense) to management my AAL concept to several different companies and to my team members, because it does work. In other words, I've combined using the right software architecting techniques AND Agile Programming techniques for success. They are both required. If that gives you any food for thought, let me know! Marc
Thanks for your feedback (double so since it's encouraging ;) ) I got to read you AAL article later - I'm a bit unfocused right now. But you're right: that's one thing that was bugging me: Which designs are good for AP (I just wrote that "many will fit the same result" to cover this shortcoming of my article...) I don't think we should avoid writing code that needs to be refactored - we should just pick designs that avoid large-scale refactorings. IMO, Refactoring is once a tool to "design on your way" (I think this part you can't avoid), and second a tool to avoid complete rewrites of large portions (this we should avoid). On the design principles: Together with the Agile techniques, at least new design techniques have gotten more attention (User Stories, Patterns, etc.) And although I feel I could "sell" them, it feels incomplete for me. It's just other techniques pointing out possibilities - but IMO requires experience to pickj the right ones nonetheless. Wel, I'll read your article first ;)
As James Bond in "die another day", Pierce Brosnan features traits handy in the dawning millenium. He fights without hesitation in a bewildering environment, trusts his high-tech-gadgets, and rather falls for beauty than pondering the political absurdities around him. [sighist]
-
I read your article and I think it is written well. I would suggest that you include an overview where you list your 5 points (the ones in blue) by themselves before the main body of the article. I don't think it is too long. One thing that I would suggest covering is how to plan for refactoring. What I mean is to tell how to develop code that is intended to be refactored. Sometimes it is necessary to "find" a solution before you can code it properly. Unfortunantely, many times this "experimental" code becomes part of production systems. Planning for refactoring at this level is important because it recognizes the reality of the likelihood of the code finding its way into production systems and it makes the refactoring more productive. If you plan for refactoring you will not leave off application-critical steps (like validating inputs, checking errors, catching exceptions, etc), instead you will keep your design simple but your code well written. One questionable aspect of AP techniques is that it focuses too heavily on ultra small time-frames and tends to make a developer rely on the compiler too heavily. I find that being able to focus on a code related problem as a whole problem, not just as a component of the problem is often more effecient and ultimately more productive than time-slicing the problem into smaller compoenents. This does not necessarily go against AP, but on the surface seems to. Also, one of the strengths most developers have is the ability to keep lots of "state" info in their heads at a time as long as it is focused. AP often tends to limit the amount of focus a developer uses by time-slicing everything and I believe reduces the total amount of "state" a developer can handle because while I can remeber 7 related things at a time, I can only remember 4 unrelated things at a time. All-in-all, a good article.
Thanks for your feedback! I share some of your doubts about AP - I see it as just one tool, that has some simple, "feeling natural" techniques to keep complexitiy managable; AP alone is for sure not sufficient! I updated the sketch with an "Limits of AP" section, including these doubts. (I want to prof-read tomorrow, than upload it here). State: IMO keeping lots of state information is prerequisite for a good programmer, and Agile techniques can greatly reduce the amount of state information that's necessary to keep in mind at one time. I don't quite understand what you mean with AP forcing you to remember unrelated things - can you elaborate this?
As James Bond in "die another day", Pierce Brosnan features traits handy in the dawning millenium. He fights without hesitation in a bewildering environment, trusts his high-tech-gadgets, and rather falls for beauty than pondering the political absurdities around him. [sighist]
-
Thanks for your feedback! I share some of your doubts about AP - I see it as just one tool, that has some simple, "feeling natural" techniques to keep complexitiy managable; AP alone is for sure not sufficient! I updated the sketch with an "Limits of AP" section, including these doubts. (I want to prof-read tomorrow, than upload it here). State: IMO keeping lots of state information is prerequisite for a good programmer, and Agile techniques can greatly reduce the amount of state information that's necessary to keep in mind at one time. I don't quite understand what you mean with AP forcing you to remember unrelated things - can you elaborate this?
As James Bond in "die another day", Pierce Brosnan features traits handy in the dawning millenium. He fights without hesitation in a bewildering environment, trusts his high-tech-gadgets, and rather falls for beauty than pondering the political absurdities around him. [sighist]
peterchen wrote: I don't quite understand what you mean with AP forcing you to remember unrelated things - can you elaborate this? AP does not force you to remember unrelated things, but it limits the amount of "state" you need to remember for a given task. This is OK for some sitations (and on the surface sounds like a good thing) and can make quick-and-dirty maintenance and refactoring work quicker. However, the results are more limited than what can be accomplished when the ultimate intent is to refator a whole problem instead of a tiny part of it. When a programmer gets in the -zone-, solving a larger problem is often more effecient than solving just a tiny part of it. Failing to leverage the -zone- and failing to allow a programmer to use his ability to maintain "state" limits the possibilities and productivity of that programmer. Also, (back to the original question), because a programmers skill of "state" recall is not used for the task at hand it tends to mean that the programmer will need to shift from one task to another relatively quickly. Shifting tasks is often the most ineffecient task for programmers which is where my remark came from. Just my 2 cents.
-
I read your article and I think it is written well. I would suggest that you include an overview where you list your 5 points (the ones in blue) by themselves before the main body of the article. I don't think it is too long. One thing that I would suggest covering is how to plan for refactoring. What I mean is to tell how to develop code that is intended to be refactored. Sometimes it is necessary to "find" a solution before you can code it properly. Unfortunantely, many times this "experimental" code becomes part of production systems. Planning for refactoring at this level is important because it recognizes the reality of the likelihood of the code finding its way into production systems and it makes the refactoring more productive. If you plan for refactoring you will not leave off application-critical steps (like validating inputs, checking errors, catching exceptions, etc), instead you will keep your design simple but your code well written. One questionable aspect of AP techniques is that it focuses too heavily on ultra small time-frames and tends to make a developer rely on the compiler too heavily. I find that being able to focus on a code related problem as a whole problem, not just as a component of the problem is often more effecient and ultimately more productive than time-slicing the problem into smaller compoenents. This does not necessarily go against AP, but on the surface seems to. Also, one of the strengths most developers have is the ability to keep lots of "state" info in their heads at a time as long as it is focused. AP often tends to limit the amount of focus a developer uses by time-slicing everything and I believe reduces the total amount of "state" a developer can handle because while I can remeber 7 related things at a time, I can only remember 4 unrelated things at a time. All-in-all, a good article.
I don't believe you should plan for refactoring. Any code can at some time become obsolete, be it after 2 days or 2 years. That's when you refactor it, even if it's in production. I love the notion of "good enough" to decide for or against refactoring some code. For the state problem, I often make the "mistake" to think too much in high-level states, eating up my human RAM. Ultra small time-frames let me write down some states for later retrieval and free the memory I need for a better focus on the problem at hand (and a better schedule). As AP is very much human-centered, it's not a solution but rather a "programming philosophy" that can work or not the same depending on you. Eric