alreadyused
Well-known member
- Joined
- Jan 13, 2006
- Messages
- 70
I
looking for some guidance
- Thread starter alreadyused
- Start date
mskeel
Well-known member
Project Management Approaches
For your first bullet, obviously, it depends, but from what Ive read and my own experiences there are at least two approaches you can take to managing the project.
The first is to get out of the way and let folks do their jobs. This means letting the coders and testers do their thing, and you make sure that they can do their thing without being bothered. This means protecting them from as much office bologna as possible: schedule stuff, meetings, money stuff, presentations, fighting feature creep from marketing, and so on. With this approach, you should be spending most of your time doing high level vision types of activities and, again, protecting your coders from all the junk that just gets in the way. Unfortunately, this means that you dont get to do too much coding and none of the code you write should be [schedule] blocking. In other words, you dont get to write code for the most important parts of the system.
The other approach is the "Surgical Team" approach (Fred Brooks) in which you are the pilot of the project and your team supports you. Not only do you have the primary vision in this case but you also do the majority of the coding and only bring other folks on for very specific tasks as they are needed. Tasks can range from anything to coding specific sections of the system to writing documentation to preparing presentations or even secretarial duties.
Ive used both of these approaches on different projects and depending on the folks you work with and how much BS upper management wants, they both can work really well.
I recommend you read PeopleWare and The Mythical Man Month. Theyre both pretty quick reads and extremely informative.
For your first bullet, obviously, it depends, but from what Ive read and my own experiences there are at least two approaches you can take to managing the project.
The first is to get out of the way and let folks do their jobs. This means letting the coders and testers do their thing, and you make sure that they can do their thing without being bothered. This means protecting them from as much office bologna as possible: schedule stuff, meetings, money stuff, presentations, fighting feature creep from marketing, and so on. With this approach, you should be spending most of your time doing high level vision types of activities and, again, protecting your coders from all the junk that just gets in the way. Unfortunately, this means that you dont get to do too much coding and none of the code you write should be [schedule] blocking. In other words, you dont get to write code for the most important parts of the system.
The other approach is the "Surgical Team" approach (Fred Brooks) in which you are the pilot of the project and your team supports you. Not only do you have the primary vision in this case but you also do the majority of the coding and only bring other folks on for very specific tasks as they are needed. Tasks can range from anything to coding specific sections of the system to writing documentation to preparing presentations or even secretarial duties.
Ive used both of these approaches on different projects and depending on the folks you work with and how much BS upper management wants, they both can work really well.
I recommend you read PeopleWare and The Mythical Man Month. Theyre both pretty quick reads and extremely informative.
alreadyused
Well-known member
- Joined
- Jan 13, 2006
- Messages
- 70
Re: Project Management Approaches
Thanks for the reply!
From your examples, I would say I have been trying a blend between both, and thats probably why Im struggling.
I just ordered both the books and ill definitely check those out, thanks again for the tips and links!
Thanks for the reply!
From your examples, I would say I have been trying a blend between both, and thats probably why Im struggling.
I just ordered both the books and ill definitely check those out, thanks again for the tips and links!
In the past, Ive been a programmer, lead, and a project manager. So Ive made some of the mistakes Ill advise against. I have also suffered from others making them. In summary, my advice is to be realistic about what new technology and trends can really accomplish, to be skeptical about OOP, and to avoid upsetting the status quo. The world does not need another heavy-handed process or framework that basically just serves to prove how clever you are.
Let me share a story I have seen unfold at least twice.
A company takes a programmer and makes him a working manager or "architect." This doesnt seem like a big deal to the non-programmers in the organization. But its the first real authority the new "architect" has had, and hes enthusiastic.
The new architect disappears into an office for days, weeks, or months, and then emerges with something (e.g. a new framework, technology, class hierarchy, or process) that will change how everyone else works.
This work is not well-received by the rest of the team, who liked the way things were done before, and who wish the new architect would get back to helping them do those things.
The architect tries to sell the team on his vision, telling them how much time they will save and how many things they "wont have to worry about." This doesnt work, because those "things" are exactly what the programmers are trained and paid to "worry about," and because they need to know how their programs operate.
Eventually, a new mode-of-operation emerges. Maybe one programmer leaves. Another is transferred. A timid new programmer or two enter the organization and, knowing nothing better, attempt to work within the framework. The programmers still remaining from life-before-the-architect are bruised from their experience with the newly minted architect and his framework. They basically become legacy employees, their careers put on hold because they cant develop any enthusiasm for what happened. All of this is unfair (if you care), and a tremendous distraction from the real work of software development.
Many of these problems are unfortunate byproducts of OOP, which tells us that one group of elite coders should make "class libraries" that the rest of us idiots should just glue these together. The problem is that the "rest of us" are the ones who actually have to deliver something to the users, which is actually the hard part. OOP creates this privileged "architect" class and my #1 piece of advice is to avoid allowing that to happen. That doesnt mean avoiding OOP where it helps, it just means to be realistic.
The vast majority of the time, I say you should do the same things the programmers do. I think the "researching" aspect of your job is over-rated. My experience is that tool vendors like Microsoft are going to spend big money beating you over the head with even the most trivial new development product. Spending your time reading their glossy propaganda while the other programmers slave away is not a valid use of your time.
And I would be very careful to avoid grabbing every assignment you perceive as "fun" or "important" or even "difficult." I worked with a guy who was content to spend all his time "researching" or "reviewing" until any GUI work came down the pipeline. It was exhausting, because I always ended up getting what he didnt want, which was typically some retarded console app or class library.
At this point youre probably wondering how I think your new assignment should be any different. Well, I think you should work as first-among-equals. There are some occasions in software development where a debate or question emerges and consensus does not naturally form. Thats where you step in to break the tie, kind of like the Vice President in the U.S. Senate.
Other than that, my advice is: youre still a programmer. Return to reality. This is a job, not an outlet for whatever frustrated creative urges you have.
Let me share a story I have seen unfold at least twice.
A company takes a programmer and makes him a working manager or "architect." This doesnt seem like a big deal to the non-programmers in the organization. But its the first real authority the new "architect" has had, and hes enthusiastic.
The new architect disappears into an office for days, weeks, or months, and then emerges with something (e.g. a new framework, technology, class hierarchy, or process) that will change how everyone else works.
This work is not well-received by the rest of the team, who liked the way things were done before, and who wish the new architect would get back to helping them do those things.
The architect tries to sell the team on his vision, telling them how much time they will save and how many things they "wont have to worry about." This doesnt work, because those "things" are exactly what the programmers are trained and paid to "worry about," and because they need to know how their programs operate.
Eventually, a new mode-of-operation emerges. Maybe one programmer leaves. Another is transferred. A timid new programmer or two enter the organization and, knowing nothing better, attempt to work within the framework. The programmers still remaining from life-before-the-architect are bruised from their experience with the newly minted architect and his framework. They basically become legacy employees, their careers put on hold because they cant develop any enthusiasm for what happened. All of this is unfair (if you care), and a tremendous distraction from the real work of software development.
Many of these problems are unfortunate byproducts of OOP, which tells us that one group of elite coders should make "class libraries" that the rest of us idiots should just glue these together. The problem is that the "rest of us" are the ones who actually have to deliver something to the users, which is actually the hard part. OOP creates this privileged "architect" class and my #1 piece of advice is to avoid allowing that to happen. That doesnt mean avoiding OOP where it helps, it just means to be realistic.
The vast majority of the time, I say you should do the same things the programmers do. I think the "researching" aspect of your job is over-rated. My experience is that tool vendors like Microsoft are going to spend big money beating you over the head with even the most trivial new development product. Spending your time reading their glossy propaganda while the other programmers slave away is not a valid use of your time.
And I would be very careful to avoid grabbing every assignment you perceive as "fun" or "important" or even "difficult." I worked with a guy who was content to spend all his time "researching" or "reviewing" until any GUI work came down the pipeline. It was exhausting, because I always ended up getting what he didnt want, which was typically some retarded console app or class library.
At this point youre probably wondering how I think your new assignment should be any different. Well, I think you should work as first-among-equals. There are some occasions in software development where a debate or question emerges and consensus does not naturally form. Thats where you step in to break the tie, kind of like the Vice President in the U.S. Senate.
Other than that, my advice is: youre still a programmer. Return to reality. This is a job, not an outlet for whatever frustrated creative urges you have.
PlausiblyDamp
Administrator
One thing that I have found that can really help to prevent a them and us type of environment is frequent code reviews. These can be fairly informal and definitely do not need to be a lengthy process either - however it means everybody can get familiar will all aspects of the system (providing good coverage if a single developer leaves or is away for any length of time) while also allowing all interested parties to see what direction things are going in and what is required (this way the users of the class library get a valid chance to provide input and criticism and even contribute to it).
Getting everybody involved in producing a working product has got to be the ultimate aim (just nip over to www.thedailywtf.com and search for Enterprise or Enterprisy for examples of overblown and pointless frameworks).
For a small team it might be worth considering a more XP style of development (such as TDD) - this can reduce wasted time on over complicated design or massive frameworks and keep people focused on writing quality and necessary code.
Getting everybody involved in producing a working product has got to be the ultimate aim (just nip over to www.thedailywtf.com and search for Enterprise or Enterprisy for examples of overblown and pointless frameworks).
For a small team it might be worth considering a more XP style of development (such as TDD) - this can reduce wasted time on over complicated design or massive frameworks and keep people focused on writing quality and necessary code.
alreadyused
Well-known member
- Joined
- Jan 13, 2006
- Messages
- 70
beau, theres a few things you said that really stood out to me.
One is "...that basically just serves to prove how clever you are." I made that mistake early on, and many of times. I finally read a quote by someone that said something along the lines of code is twice as hard to debug as it is to write, so if you write something that is the most complex you can write, you wont be able to debug it. So Ive been working on keeping it simple, but that is definitely an easy pitfall.
As for the researching, I dont mean a new product, I mean some new widget that Microsoft has included in the visual studio. And by researching/learning I meant putting that to use in code, if it makes sense. An example would be generics, or threading, or whatever... list goes on. And a lot of that, I have left up to my assistant (I have had one developer working for/with me for a while, and I noticed inefficiencies on my part there... thats what really prompted me to post this). So I do see your point here, stay focused on code and try not to be distracted by shiny new tools. For the most part, I have done that, but your bringing that to my attention will definitely help me stay focused on it.
OOP. Im not saying that Im right, but I currently disagree with you on this. I do see your point, however. But the reason I disagree is this... I am a huge believer and supporter of OOP. When you understand it (again assuming I didnt get carried away on the design) it makes code easy to debug and maintain. I have fought through way too much procedural code. But I also dont take the approach of disappearing into an office or cave and coming out with some crazy design... I have involved my assistant throughout the entire process, explaining my ideas and taking feedback and input on them. So to date, I do feel that OOP has worked for me. But I hear your points and will keep those in mind.
One is "...that basically just serves to prove how clever you are." I made that mistake early on, and many of times. I finally read a quote by someone that said something along the lines of code is twice as hard to debug as it is to write, so if you write something that is the most complex you can write, you wont be able to debug it. So Ive been working on keeping it simple, but that is definitely an easy pitfall.
As for the researching, I dont mean a new product, I mean some new widget that Microsoft has included in the visual studio. And by researching/learning I meant putting that to use in code, if it makes sense. An example would be generics, or threading, or whatever... list goes on. And a lot of that, I have left up to my assistant (I have had one developer working for/with me for a while, and I noticed inefficiencies on my part there... thats what really prompted me to post this). So I do see your point here, stay focused on code and try not to be distracted by shiny new tools. For the most part, I have done that, but your bringing that to my attention will definitely help me stay focused on it.
OOP. Im not saying that Im right, but I currently disagree with you on this. I do see your point, however. But the reason I disagree is this... I am a huge believer and supporter of OOP. When you understand it (again assuming I didnt get carried away on the design) it makes code easy to debug and maintain. I have fought through way too much procedural code. But I also dont take the approach of disappearing into an office or cave and coming out with some crazy design... I have involved my assistant throughout the entire process, explaining my ideas and taking feedback and input on them. So to date, I do feel that OOP has worked for me. But I hear your points and will keep those in mind.
alreadyused
Well-known member
- Joined
- Jan 13, 2006
- Messages
- 70
PD, thanks for your reply.
First off, I saw a link a while ago to *** in this forum and try to check it out regularly. I have to admit that while I personally am not on there, some of my previous thoughts were, so that has been a bit of a humbling experience!
I like your first comment on the code reviews. Since there has only been myself plus one, this has been simple, and happens all the time. Since more people are involved I could see how this would be easy to overlook though. I could see myself trying to spend time with just that developer instead of everyone together at the same time. So I will work on bringing everyone together to review code and the designs, including mine.
On the XP, I have seen it mentioned here and there and looked into it a bit in the past. I know that the basic idea is to break it down into small, meaningful steps that can be deployed and tested as you go. I dont know much else about it other than that, so I better look into that. Thanks for the tip.
Im curious, whats your feeling about OOP?
As I said in my reply to beau, I think it is very powerful and easy enough to explain if you keep everyone involved in the entire process. I could see how this possibly takes a little longer up front, but I have personally seen that it saves time in the long run.
mskeel, if youre still watching this, do you have an opinion on the OOP?
Just as a note, I learned procedural first. It took me a while to begin to grasp OO, but I remember sitting in class one day and it just clicked.
First off, I saw a link a while ago to *** in this forum and try to check it out regularly. I have to admit that while I personally am not on there, some of my previous thoughts were, so that has been a bit of a humbling experience!
I like your first comment on the code reviews. Since there has only been myself plus one, this has been simple, and happens all the time. Since more people are involved I could see how this would be easy to overlook though. I could see myself trying to spend time with just that developer instead of everyone together at the same time. So I will work on bringing everyone together to review code and the designs, including mine.
On the XP, I have seen it mentioned here and there and looked into it a bit in the past. I know that the basic idea is to break it down into small, meaningful steps that can be deployed and tested as you go. I dont know much else about it other than that, so I better look into that. Thanks for the tip.
Im curious, whats your feeling about OOP?
As I said in my reply to beau, I think it is very powerful and easy enough to explain if you keep everyone involved in the entire process. I could see how this possibly takes a little longer up front, but I have personally seen that it saves time in the long run.
mskeel, if youre still watching this, do you have an opinion on the OOP?
Just as a note, I learned procedural first. It took me a while to begin to grasp OO, but I remember sitting in class one day and it just clicked.
mskeel
Well-known member
My opinion is that you should always try to use the right tools for the job. The way to know which are the right tools is to always be reading, always trying out new stuff, and always asking questions. Obviously if youre in crunch time to a deadline, research should be put on the back burner but if you arent learning at least a little something new everyday, then you arent taking full advantage of the internet.
This board is a great place to ask questions and learn about .Net. If you dont already use a feed reader you should think about it. Joel on Software and Coding Horror are two great blogs that cover general programming topics. Just try not to become addicted!
Back to OOP, I like it, but I think it can be bloated at times. Ive been using JavaScript a lot recently and thats been pretty cool. I really dig C# and the new features in .Net 3.5 have been exploding my brain with their awesomeness. I agree with PD, though. TDD is great and the more automation you can put into your build process, the better off youll be.
PlausiblyDamp
Administrator
One good way to get code reviews to work is schedule them for a fairly non-productive time of the week (a couple of hours on a day when people just seem to be less enthused about their work...). Encourage people to send their code to their peer reviewer a day or two before the review itself so they have a chance to look at it - on beneficial side effect is people often find it easier to do this on a more ad-hoc basis just to get feed back if they are unsure of their current approach rather than stubbornly plodding on regardless.
Try to avoid acting too overly superior in code reviews - the other developers should feel comfortable criticising your bad decisions / code just as much as each others, equally if a person can justify and defend their methods they might be right
OOP can be beneficial in this kind of scenario as a small-ish class can be delegated, reviewed and tested as a single work unit, if parts of the system can be designed in this way then delegation becomes easier e.g. in a data access layer splitting functionality such as connection management, config file handling, command creation / execution or similar into one or more classes or methods will foster a cleaner design in the long run and should produce cleaner code. Some of these ideas may only come together through communication.
Encourage people to admit when things could be done better (and give serious consideration to making the relevant changes).
Encourage relevant documentation which is appropriate to the scale and scope of a given project or task; a class itself may need no more than a simple class diagram and a couple of lines of text, a major system possibly more but with less detail.
If you have time to look at other software then the code to #develop has some very clean design practices (please be aware of the the licence it is released under before actually borrowing code though) - as very useful addition is their free book about the #develop project as it explains a lot of useful OOP terms and ideas in the context of a real application rather than a contrived scenario, plus they are quite open in admitting past mistakes and what was involved in fixing them.
Try to avoid acting too overly superior in code reviews - the other developers should feel comfortable criticising your bad decisions / code just as much as each others, equally if a person can justify and defend their methods they might be right
OOP can be beneficial in this kind of scenario as a small-ish class can be delegated, reviewed and tested as a single work unit, if parts of the system can be designed in this way then delegation becomes easier e.g. in a data access layer splitting functionality such as connection management, config file handling, command creation / execution or similar into one or more classes or methods will foster a cleaner design in the long run and should produce cleaner code. Some of these ideas may only come together through communication.
Encourage people to admit when things could be done better (and give serious consideration to making the relevant changes).
Encourage relevant documentation which is appropriate to the scale and scope of a given project or task; a class itself may need no more than a simple class diagram and a couple of lines of text, a major system possibly more but with less detail.
If you have time to look at other software then the code to #develop has some very clean design practices (please be aware of the the licence it is released under before actually borrowing code though) - as very useful addition is their free book about the #develop project as it explains a lot of useful OOP terms and ideas in the context of a real application rather than a contrived scenario, plus they are quite open in admitting past mistakes and what was involved in fixing them.
alreadyused
Well-known member
- Joined
- Jan 13, 2006
- Messages
- 70
After I posted my reply to beau, I got to thinking... I work in a wierd environment, and there typically are no small projects. So that is the reason that I tend to lean to the OOP side. And my first reaction was post-war trauma syndrome, thinking back to the pages upon pages of proc code Ive had to dig through... but then I remembered that there have been a few apps where to add OOP would have been silly.
So mskeel, your quote about the right tools is right on with that, thanks for the reminder.
PD thanks for the suggestions on the code review, that makes sense sounds like theyll work and Ill give that a shot.
Ive been working on the Head First Design Patterns book, tasty! They do a good job of making sure you learn it too, if you follow the instructions. Another nice thing about it is it had been several years since I used java; that got that back in my system, and also gave me the push to do more in c#.
Anyway, Im out for a week or so, thanks to all for your comments and suggestions, I really appreciate it.
au
So mskeel, your quote about the right tools is right on with that, thanks for the reminder.
PD thanks for the suggestions on the code review, that makes sense sounds like theyll work and Ill give that a shot.
Ive been working on the Head First Design Patterns book, tasty! They do a good job of making sure you learn it too, if you follow the instructions. Another nice thing about it is it had been several years since I used java; that got that back in my system, and also gave me the push to do more in c#.
Anyway, Im out for a week or so, thanks to all for your comments and suggestions, I really appreciate it.
au
mskeel
Well-known member
PlausiblyDamp, Ive seen a little discussion on the web recently comparing and contrasting pair programming to formal code reviews. The general gist is that pair programming can be just as good as formal code reviews since, in essence, by programming in pairs the code is constantly being peer reviewed. What are your thoughts?
Ive used code reviews a few times and I found them effective but difficult to justify with a small team. Pair programming might be an easy way to get the benefits of code review without the formalism. Maybe.
Ive used code reviews a few times and I found them effective but difficult to justify with a small team. Pair programming might be an easy way to get the benefits of code review without the formalism. Maybe.
Similar threads
- Brian T. Horowitz, Network Computing
- General Tech Help & Discussions
- Bloomberg News
- General Tech Help & Discussions
- Bloomberg News
- General Tech Help & Discussions