How do I avoid a development disaster on my next project?



  • Yesterday I read Alex Papadimoulis's article Development Disasters: Prevent your next software project from becoming a train wreck, in the August 1, 2007 issue of RedmondDeveloper magazine.  That article really applies well to me, as I'm tasked with being the project lead on doing a re-write of one of our primary applications.  It desparately needs to be re-written, as it is very old and beginning to fail a lot.  Something that I gained from Alex's article is that the primary predictor of how well a project will succeed is the people involved in the project, and that is what has me worried the most.

    The application we're going to re-write was written about 9 years ago in VB5 (later upgraded to VB6).  It uses 3rd party controls that have long since stopped being supported, and half of the time the controls are the things that fail.  But the other half of the time the application fails because of all of the patches and kludges that have been added to it.  It has become such a huge maintenance headache that re-writing it has become the best option.

    My concern is the team that I have to work with.  We are a 3 person team, one of which is the supervisor.  His supervisory duties consumes most of his time.  I know that he would like to help, and when he is available he can help.  His programming skills are good - it is just his time he hasn't got a lot of.

    The other people is an older fellow, who I believe has given up in his pursuit of keeping himself and his skillset current.  He tends to complain a great deal about development tools, which seem never to be adequate for him.  His development environment tends to always somehow be corrupted.  I've tried to figure out why something which works fine on both my machine or our supervisor's machine, doesn't work on his, and it is way beyond me.  I suspect that he edits important system files so horribly that it just stops working.  He has uninstalled and reinstalled Visual Studio, for example, in an effort to get things working, but then in short order he is in a mess again.

    And then there is me.  I am a good deveoper, and look forward to this re-write, but it is a big project and I don't want to do it all alone.  When I was involved in the original project writing this application it took 4 developers including myself (3 of which were very good and one who was not, but thank God she is now gone) to finish the project in about 8 months.  I estimate a smilar time line this time around, but I have less to work with.

    However, I have to work with it.  I believe our supervisor will be fine, when he can get the time to help.  My biggest concern is the older fellow.  How do I engage him in a meaning ful way in the development of this project and yet not have him work on anything too critical?



  • Seems to me the biggest threat to your project (and your sanity) is the 'older guy' in your team, and not management / poor 3rd party tools / etc (i.e. the usual reasons for failure).

    His 'issues' with the development environment might not affect matters much in the early stages of the project, but it's bound to cause friction when the deadlines loom.

    If you really believe that he is going to be difficult to work with then I suggest you confront your supervisior sooner rather than later.  This might not be an easy thing to do, but it's better than having a failed project and all the misery that that entails.

    Whilst you're at it you might ask him/her whether they will be able to get their hands dirty on the project (otherwise it sounds like it will just be you!)

    Best of luck 



  • Suggestion: before you start, read Joel on re-writing code.  Some good pointers. Good luck.



  • @vr602 said:

    Suggestion: before you start, read Joel on re-writing code.  Some good pointers. Good luck.

    Interesting read, but I don't fully agree with what he says. Especially the bit about the extra bug fixes in some two-page function: if you have bug fixes in code, without comments telling you why they are there, then you have a more serious issue than needing to re-write code.

    Most programming errors aren't because people can't program but because they cannot (or more often, will not) communicate.  The number one mistake about coding in my experience is the idea "the code is the requirements". That's absurd, because code can only tell you what it's doing, not what it's supposed to do. Those are very subtly different things - you can't even test code if you don't know what it's supposed to do.  And I mean really know what it's supposed to do.  Take, for instance, a seemingly simple requirement: "Add two numbers".  Well, what kind of numbers? In what range? What do you do if the numbers are out of range? How do you want the result? How do you indicate errors? Does it have to be thread safe?  Once you answer those questions, then you can code. If you have a function that just says "return A + B", then the implicit requirements are "add two numbers. All input validation and error checking is handled elsewhere," which may or may not be the case, and you have to dig around a lot to find out why.

    If people knew the requirements, and documented things (yes, I know that takes away from the "actual coding time"), and put in comments (or better yet, had an issue tracking system which was referenced in comments) saying why a code change was made, then rewriting code would be simple, because you'd just be re-implementing requirements rather than trying to interpret undocumented code.

    So I would extend Mr. Spolsky's statement to "The single worst strategic mistake you can do in programming is completely rewrite undocumented code."



  • Hey, freaky, the little blue boxes below my avatar disappeared!

    (May or may not be visible on your system - yay for often-nondeterministic computer behavior!)



  • @too_many_usernames said:

    So I would extend Mr. Spolsky's statement to "The single worst strategic mistake you can do in programming is completely rewrite undocumented code."

    So completely rewriting documented code is okay?



  • @dhromed said:

    @too_many_usernames said:

    So I would extend Mr. Spolsky's statement to "The single worst strategic mistake you can do in programming is completely rewrite undocumented code."

    So completely rewriting documented code is okay?

    The only answer appropriate here is, "It depends."  In general I'd say it's probably not necessary, but that's agnostic to the fact if it is ok or not ok.  It also depends on what you mean by "rewrite".  In my mind, updating a function, refactoring it, etc. is a form of "rewriting".  Bug fixes are actually re-writing, too.

    But to start from scratch to do the same exact thing, yeah, doesn't seem like the best thing, but I doubt it's the worst.

    (And now the blue boxes are back...interesting!)
     



  • @Doctor Who said:

    My biggest concern is the older fellow.  How do I engage him in a meaning ful way in the development of this project and yet not have him work on anything too critical?

    He is a useless third wheel. Trust me, I've dealt with the type. There's no way you can change them. I would send him on various "wild goosechases" just to keep him occupied. Have him research obscure programming topics and come up with proof of concepts for the team. Alternatively, you could tell him to work on fixing his local environment, which would keep him occupied for weeks. 



  • I just realized.... that older person is in fact CPound.


Log in to reply