looking for some guidance

A

alreadyused

Regular
Joined
Jan 13, 2006
Messages
69
I’m looking some pointers, advice, suggestion, etc. I am having a hard time balancing it all, and am curious what methods work best for everyone out there.

Up until now it has been myself plus one, and I have had the lead role. That person is very fast, but also very impatient, so I have found myself having to be more detail-oriented than I would like. That also means that there are a lot of concepts and tasks that I have to have intimate knowledge of. While I definitely enjoy learning new concepts, that also takes a lot of time. (I am not comfortable with just doing something because it works... I like to understand why) Along with this, it means that I typically have to tackle the more complex tasks. And the more I do of that, the less time I have to stay focused on the big picture, which slows me down and the whole project down.

Looking back on it, I’m guessing if I allocated a certain amount of time each week for researching the unknowns and new topics, and started that as soon as they arise, that I would be spending less time reacting to the issues in the end, but I’m not sure.

Going forward, I will be working with the current developer plus two others, and I will have the lead role. What I’m really looking for is any tips that you may have that you found work well, and why. If it seems like a common sense thing, please mention it anyway.

I know going into this, because of my knowledge of the product we're writing the software around, that I'm going to have to write some portions of the code.

For others who are in this situation or have been in this situation, do you have any pointers?

Here are some specific questions I have:
  • How much code do you write, percentage-wise, versus how much you assign?
  • Is there certain code that you prefer to write versus hand off?
  • How many new topics are you comfortable taking on in a package?
  • Do you have any rules on how you spend your time, ie design, writing code, reviewing code, researching new topics?

Outside of that I'll take any other tips or suggestions that anyone may have as well.

TIA!
 
Project Management Approaches

For your first bullet, obviously, it depends, but from what I've 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 don't get to do too much coding and none of the code you write should be [schedule] blocking. In other words, you don't 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.

I've 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. They're both pretty quick reads and extremely informative.
 
Re: Project Management Approaches

Thanks for the reply!

From your examples, I would say I have been trying a blend between both, and that's probably why I'm struggling.

I just ordered both the books and i'll definitely check those out, thanks again for the tips and links!
 
In the past, I've been a programmer, lead, and a project manager. So I've made some of the mistakes I'll 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 doesn't seem like a big deal to the non-programmers in the organization. But it's the first real authority the new "architect" has had, and he's 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 "won't have to worry about." This doesn't 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 can't 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 doesn't 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 didn't want, which was typically some retarded console app or class library.

At this point you're 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. That's 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: you're still a programmer. Return to reality. This is a job, not an outlet for whatever frustrated creative urges you have.
 
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.
 
beau, there's 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 won't be able to debug it. So I've been working on keeping it simple, but that is definitely an easy pitfall.

As for the researching, I don't 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... that's 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. I'm not saying that I'm 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 didn't 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 don't 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.
 
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 don't know much else about it other than that, so I better look into that. Thanks for the tip.

I'm curious, what's 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 you're 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.
 
...do you have an opinion on the OOP?
Click to expand...
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 you're in crunch time to a deadline, research should be put on the back burner but if you aren't learning at least a little something new everyday, then you aren't taking full advantage of the internet.

This board is a great place to ask questions and learn about .Net. If you don't 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! :D

Back to OOP, I like it, but I think it can be bloated at times. I've been using JavaScript a lot recently and that's 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 you'll be.
 
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.
 
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 I've 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 they'll work and I'll give that a shot.

I've 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, I'm out for a week or so, thanks to all for your comments and suggestions, I really appreciate it.

au
 
PlausiblyDamp, I've 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?

I've 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.
 
Back
Top