Your first big challenge...getting the developers on board.
Your In my last article I put for the theory that the most important thing to do when considering a new methodology, especially something as far reaching as CM (or as I have renamed it, Integrity Management - I can do that, its my article), is make sure you have the support of your developers. They are smart folks and it is much better to have them on your side than against you. So how do you do that? How do you get a bunch of "I'll do it my way, thank you" hermits to agree to do extra work for the good of the project? The most obvious way to me is to show them that it really is for the good of the project. Most developers really do want their projects see the light of day and very few I have met actually want a project to fail. But you have to keep in mind that if they have been doing this kind of work very long they have been fed many lines about a new framework, a new development methodology, or a new tool that is supposed to make their job easier and the end result more reliable. They are going to be skeptical, and that is a good thing. I personally don't want a bunch of gullible developers who jump on the next newest new thing that comes out. I like to see some caution when it comes to changing things that can make or break development project.
I once worked for a small company that prided itself as one of the only "Microsoft Premier Partner" shops in the area. They stuck Microsoft posters all over the place and hung the Premier Partner plaques (the clear plastic ones with Bill Gates "signature" on them) in the front lobby. They plastered their web site with Microsoft logos and "awards" (MVP, MCDS, MCP, etc.). It was pathetic.
Needless to say, when Microsoft came out with a new technology (or a repackaged existing one), our company president couldn't contain his ecstacy. He would have the admins immediately load it on a server and start "taking it for a spin". For the next two weeks we developers would get a constant barrage of emails with code snippets in them and subjects like "LDAP is so easy with this new _______" or "S-WEEET..Exchange interactivity via XML SOAP Protocol", or whatever. You get the idea.
Inevitably within a few weeks he would have satisfied himself that this new technology wsa top notch and ready for prime time, even if Microsoft hadn't (Or as he would yell from his office at regular intervals, "Rock On!"). He would then have all of the developers drop the work we were doing on real customer requested features and bugs and start recoding the entire app for whatever this new technology was. I was coding in .Net in late 2001 and early 2002, back when even Microsoft considered it Alpha. Not in "hello world" projects, but in the company's main product, a very large home healthcare system.
To keep this environment going, you can't afford to have any devlopers who were cautious or thought for themselves. They all had to toe the line and follow the Microsoft lead in everything. We added remote messaging to the application to report application errors. Why? Because these things called "sinks" in the Enterprise Application Architecture Library COULD. No other reason needed. He also had us require the user to enter a description of the error and what they were doing when it occurred. Apparently (as I predicted) there is a particularly troublesome area of the application commonly referred to as "asdf", because that is what most of the replies contained. Some of them were more colorful and described what the computer (and by extension, we developers) could do with the error message. Little was left to the imagination on those. Did I mention that once we got the entire application converted to .Net (by then it was in Beta), we started converting the whole UI to Infragistics .Net Ultragrids? Those were beta as well and oh, boy what a bucket of fun that was!
Looking back, I see now that what that shop needed was a few skeptical developers who would stand up and say "that's dumb and I am not going to do it". At the time I was so happy to be back at work after a six month dry spell that I wasn't going to do it. But I should have.
After this experience, I am naturally cautious of any developer that responds to an announcement that we are going to "re-architect", "re-design", or "re-implement" anything, much less the way we control the changes that happen in an application development cycle with anything other than objection. So the first rule is: If nobody objects, be careful; they are either new graduates who haven't learned yet, or they don't plan on doing it anyway. They are just trying to get you to go away so they can get back to coding.
If they are good at what they do, you will get instant pushback in the form of "Oh, so this is going to fix all of our problems just like “Agile” did? Or was it “CMMI” that was going to do that? No, wait, I think it was “RUP” or maybe it was ___________!
Don’t panic; this is a good sign because if they are skeptical and you bring them around, you will know that they are sincere about doing it, and if you have been led down the primrose path by me, they will let you know where the gaps are.
As I mentioned in my last article, the way to the developer's heart by making his job easier, but only if it appeals to his built-in logic processor. Less "stupid _ _ _ _" and more development power is the key. A good developer can spot the holes in any logic from five miles up, so you have to know that what you are advocating is sound. Once you appeal to their sense of logic ("hey, you know, that makes a lot of sense!") and you demonstrate how it will make their job easier by taking the bull off of them, you will win them over.
I know this because I am, at heart, a developer and I have never been convinced of the value of CM until recently. In fact, it took me approaching CM the same way I would any other project to get it broken down to the point that it made sense.
The next article will begin to describe a system of project integrity control that is based on very sound, very flexible and very simple logic. We will start at the most basic level of tracking and expand it to show how it can be applied to any project, no matter how complex it is. I hope you come back to read it.
M@
I once worked for a small company that prided itself as one of the only "Microsoft Premier Partner" shops in the area. They stuck Microsoft posters all over the place and hung the Premier Partner plaques (the clear plastic ones with Bill Gates "signature" on them) in the front lobby. They plastered their web site with Microsoft logos and "awards" (MVP, MCDS, MCP, etc.). It was pathetic.
Needless to say, when Microsoft came out with a new technology (or a repackaged existing one), our company president couldn't contain his ecstacy. He would have the admins immediately load it on a server and start "taking it for a spin". For the next two weeks we developers would get a constant barrage of emails with code snippets in them and subjects like "LDAP is so easy with this new _______" or "S-WEEET..Exchange interactivity via XML SOAP Protocol", or whatever. You get the idea.
Inevitably within a few weeks he would have satisfied himself that this new technology wsa top notch and ready for prime time, even if Microsoft hadn't (Or as he would yell from his office at regular intervals, "Rock On!"). He would then have all of the developers drop the work we were doing on real customer requested features and bugs and start recoding the entire app for whatever this new technology was. I was coding in .Net in late 2001 and early 2002, back when even Microsoft considered it Alpha. Not in "hello world" projects, but in the company's main product, a very large home healthcare system.
To keep this environment going, you can't afford to have any devlopers who were cautious or thought for themselves. They all had to toe the line and follow the Microsoft lead in everything. We added remote messaging to the application to report application errors. Why? Because these things called "sinks" in the Enterprise Application Architecture Library COULD. No other reason needed. He also had us require the user to enter a description of the error and what they were doing when it occurred. Apparently (as I predicted) there is a particularly troublesome area of the application commonly referred to as "asdf", because that is what most of the replies contained. Some of them were more colorful and described what the computer (and by extension, we developers) could do with the error message. Little was left to the imagination on those. Did I mention that once we got the entire application converted to .Net (by then it was in Beta), we started converting the whole UI to Infragistics .Net Ultragrids? Those were beta as well and oh, boy what a bucket of fun that was!
Looking back, I see now that what that shop needed was a few skeptical developers who would stand up and say "that's dumb and I am not going to do it". At the time I was so happy to be back at work after a six month dry spell that I wasn't going to do it. But I should have.
After this experience, I am naturally cautious of any developer that responds to an announcement that we are going to "re-architect", "re-design", or "re-implement" anything, much less the way we control the changes that happen in an application development cycle with anything other than objection. So the first rule is: If nobody objects, be careful; they are either new graduates who haven't learned yet, or they don't plan on doing it anyway. They are just trying to get you to go away so they can get back to coding.
If they are good at what they do, you will get instant pushback in the form of "Oh, so this is going to fix all of our problems just like “Agile” did? Or was it “CMMI” that was going to do that? No, wait, I think it was “RUP” or maybe it was ___________!
Don’t panic; this is a good sign because if they are skeptical and you bring them around, you will know that they are sincere about doing it, and if you have been led down the primrose path by me, they will let you know where the gaps are.
As I mentioned in my last article, the way to the developer's heart by making his job easier, but only if it appeals to his built-in logic processor. Less "stupid _ _ _ _" and more development power is the key. A good developer can spot the holes in any logic from five miles up, so you have to know that what you are advocating is sound. Once you appeal to their sense of logic ("hey, you know, that makes a lot of sense!") and you demonstrate how it will make their job easier by taking the bull off of them, you will win them over.
I know this because I am, at heart, a developer and I have never been convinced of the value of CM until recently. In fact, it took me approaching CM the same way I would any other project to get it broken down to the point that it made sense.
The next article will begin to describe a system of project integrity control that is based on very sound, very flexible and very simple logic. We will start at the most basic level of tracking and expand it to show how it can be applied to any project, no matter how complex it is. I hope you come back to read it.
M@
[0] Comments:
Post a Comment
<< Home