Fog Creek Software
Discussion Board




Teaching Lazyness

Hello all.  I am the de-facto project manager for a .NET project we're scheduled to start shortly.  Our small team is divided roughly 50/50 between crusty old warhorses and young, energetic developers.  The latter are a cause for some concern.

I am having trouble imparting the lesson "just because you can do something, doesn't mean it's a good idea".  The world is full of articles and techniques that are "cutting-edge", but really serve to make simple concepts more complicated than they need to be.

I'm sure many here have run into the "lets make everything a COM object", "let's make all our classes STL generics" camps.

Our culture here is usually fairly "hands-off".  Developers get substantial leeway to make mistakes, but we maintain our own modules, so there's a healthy negative-feedback loop there.

This will be a mammoth project, lasting at least three years in development, and it's crucial to keep the underlying initial code clean and simple.  Without being a beaurocrat and crushing creativity, how should I push this project in the proper direction?

Anyone with anything to add, or who just wants to complain about similar coding attitudes, feel free to chime in.

My name is Bill Carlson, and I am the CrustyCoder.

Bill Carlson
Tuesday, March 12, 2002

Right off the bat, I have questions your project timeline of three years.  More context would be appreciated here.

As for your attitudes about leeway for developers, I think its a necessary evil.  Strict enforcement of the use of certain design patterns, techniques, etc. can stifle the development process.  On the other hand, there are some efficiencies to be gained.  As long as all of the developers do their own design work for their components, and have a good understanding of the constraints of the project as a whole, it should work. 

randy
Tuesday, March 12, 2002

I have to run in a couple minutes, but two things strike me as inputs to solve this problem:

* specification
This mammoth project -- is the first phase spec-writing?  Will the entire team be working on the spec, or just a subset which will set the tone for later development? 

* code reviews
Are you planning on doing this?  I suppose this is a specific case of quick feedback loops, like mentoring.

Michael Chernin
Tuesday, March 12, 2002

You need to set the tone of the approach.  That is your job. 

Specs should take months on end.  The rules, data model, prototypes, etc...  The youngsters may never even done this, as they may never have worked on a complex project.


On that topic,  is there a commonly accepted methodology for app dev these days?  You know,....

anaysis phase: cost/benefit research, project overview, scope....

design phase:  prototypes, calculations, data model, etc

constrction:

testing:




etc

n/a
Tuesday, March 12, 2002

Thanks to all who responded.  Our market is vertical market accounting apps.  This is a fairly slow moving market and we will be developing a product to handle project cost management for construction, billing, AR, AP, GL, etc.  A 3 year development cycle is feasable for us.

I agree with Randy, that leeway is important.  That's always been my position and I've never been "stifled" at this job or been the "stifler".  The main skill our team needs to develop is "cost-benefit analysis".  Unfortunately, this is usually hard for younger technical people.  Often, they will see a new API come out with 25 classes and feel they need to use each one somehow.  Our product will sell for a small amount of money (under $10K), so we can't absorb technical support or deployment issues incurred by using "the kitchen sink".  This needs to be a technically simple, reliable, and boring product.  Our clients neither need nor appreciate "cool".

We can solve some of this through detailed specs and code reviews.  That level of formality is somewhat foreign to our organization, but might be overdue.

Our company has experience maintaing an existing product, but no experience (other than my own) undertaking a large new effort.  Right now, I'm the technical guru here, but may need to expand my role to include mentoring (as Michael C. mentioned) and some project management.  I don't want to bite off more than I can chew, being only 28.  We have quality management, but they are somewhat naive to the development process.  It scares them, which is a good start, I guess!

Has anyone else had to get the younger guns to "tone it down" with their code?

Anyway, thanks for listening to my rant.  Feedback is appreciated!

Bill Carlson
Tuesday, March 12, 2002

Just turning 30, I am just getting over my 'Young Gun' stage.  The only way to get them over it is for them to get burnt - the negative feedback loop.

The problem you have is that its 3 years to delivery, so you can't rely on them getting that useful experience.

I think you need some smaller projects to 'break them in.'  At the moment its like Christmas morning, and they want to play with their new toys.  Let them get it out of their system and they will all be gathering dust by New Years Day.

Perhaps you can create some minuture projects, creating support tools for development?  Something with on a small scope so they can start to understand the whole cycle and the payoffs involved.

Ged Byrne
Tuesday, March 12, 2002

If the inexperienced hot shot programmer comes up to you and says you should use, for example, bleeding edge XML and Web Services (oops, isn't that what .NET is all about), and you think that good old proven technology will work just fine, your job is to convince him you're right. For example:

- Discuss with him how specifically using XML and Web Services is going to improve (or not) readability, stability, performance, reduce line count and other agreed on values related to your requirements.

- Ask him to provide a detailed estimate of development time and a risk analysis using this cutting-edge technology as opposed to using proven technology.

Hopefully, you can convince him, using real arguments, that cutting edge may not be so hot after all.

B
Tuesday, March 12, 2002

I manage a small group and have the same problems. New stuff is interesting, the same old is dull. You have to fight that at every turn.
First, you said this was a new undertaking at your company. If you want to be successful, learn about project management. You may be the guru now, but plan on coding less and less and managing more.
Second, I do not for a minute believe that you write a spec and turn the coders loose. Learn the Socratic method. Talk your people through the detailed design. You don’t have time to code it, but you should understand it. Ask “Why?” like a four year old. You employees should know there is no hand waving at the boss and he will leave you alone. Everything must be justified, every trade off explained, every interface understood. Never let a programmer put something in just because it is cool or new. If they can’t give you three reasons why it is good and three why it is bad, they don’t know enough to use it.
If one of your programmers does add anything you have not discussed, make them remover it.
Third, your part of this is to keep and communicate the big picture. The coders will have their heads down, typing away. You need to keep them informed. You must control what gets added for the greater good. One programmer who has had a class in blah cannot use blah because no one else will understand.
This works because you work out the detailed design with the programmer. You get to be the overall architect, but code less. The programmers still have a major role in the design. Everyone is happy.

Doug Withau
Tuesday, March 12, 2002

B said:

If the inexperienced hot shot programmer comes up to you and says you should use, for example, bleeding edge XML and Web Services (oops, isn't that what .NET is all about), and you think that good old proven technology will work just fine, your job is to convince him you're right.

No, it's his job to convince you that he's right. As you say, there must be a cost/benefits/risk analysis done, but if I'm in charge, _they_ must convince _me_ that they know what they're talking about, and that their proposal is worthwhile, because _I'm_ the one who has to justify it further up the line.

At my previous job, I saw a new-development project die that half the engineering department had been working on for three years. This was in the early 80's, and the company had split off the "hot-shot/fast-track" managers for the project from the rest of engineering, then staffed the project with new college graduates because "they know Unix already." Some of these kids were hired in at half again the salaries of those of us with several years experience, and effectively none of them had ever delivered any significant project before.

At my current job, we had a project go somewhat sour when an employee (no longer with us) decided that his MS degree was more significant than the cumulative decades of experience in the market that his supervisors had, therefore he didn't need to pay attention to what they wanted.

When you have a development team split between experienced people and inexperienced people, the experienced people _must_ set the direction. The suggestion that Ged made about providing smaller "tools"projects to let them get cutting-edge development out of their systems is a good one.

Steve Wheeler
Tuesday, March 12, 2002

Steve - I think I meant to say that his job was to convince himself that he's wrong. Anyway - the whole convincing back and forth deal has more to do with having a healthy technical discussion about the choice of technology as opposed to telling him that "this is how we'll do it because I'm more experienced than you - and besides, I'm your boss."

Doug - I loved your "3 reasons why it's bad" - will have to remember that!

B
Tuesday, March 12, 2002

Some great ideas here.  I'm realizing that sales and marketing skills are vitally importing to project management.  Not to the outside world, but to your own team.

I went to SD-Live last year and attended some of the advanced C++ sessions.  There were mainly sharp, experienced C++ developers in there basically to see "something new" in C++.  I found these topics facinating, but of little use.  One of the things that works against all of us are the endless streams of articles on advanced COM techniques, esoteric design patterns, etc.  These are out there, because people need something to talk about and the magazines need to write about interesting stuff.  Usually no harm done, but when a developer (or worse, a manager) gets a hold of this stuff, it can be dangerous, because you're in the position of having to argue against an "expert".  It's the whole "Simplify your user interface with XSLT" syndrome.

Anyone run into this?

Bill Carlson
Tuesday, March 12, 2002

From another crusty old coder...

With a timeline like three years, I expect you'll end up doing one of two things:

a) get a working framework up in a few weeks, and spend the next three years refining it

b) debate, using paper and design tools for 2.75 years, then spend the last few weeks hacking together something that can be sold.

In my experience, no software that was written by more than five people in more than six months was worth bothering with.  There are doubtless a few exceptions to this, but I'd be willing to bet that every counter-example, once sufficiently examined, will show a working prototype was produced in the first six months by a small core of developers.  Nothing is more useful than working code.  Nothing will better showcase good design, or glaring errors.  Nothing will do a better job of allowing experimentation with UI, or outside components, or tools. 

Any by the time those three years are over, many of those "bleeding edge" technologies will either be well-entrenched or moribund, so there's little point in worrying about that with such a timeline.  Make the damn thing work, then make it work better, then make it better still. 

James Montebello
Tuesday, March 12, 2002

Focus on Interface designing.  Whether that interface turns out to be a C header file or a COM interface depends on the subsystem, calling system etc.  There is nothing wrong with specifying eveyrhting in an IDL fo MS programming, even if you decide that you don't want to create COM compnenets for them.  At least It keeps you interface deinition in a single place.

Of Course with .NET, you may end up focusing moreon the XML DTDs used to describe the interface between two web services, but the net effect is the same.

Use the nergy of the Young Bucks to your advantage.  If you are doning a .NET project, no one understands C# yet.  Let someone that doesn't have lots of valuable C++ etc experince go and learn the new language. 

I also recommend pair programming.  Pair a Crufty geezer with a wet behind the ears young buck and you will be surprised...they both will learn something.

Adam
Tuesday, March 12, 2002

> we will be developing a product to handle project cost management for construction, billing, AR, AP, GL,

Are you reinventing the wheel?  Don't apps like Lawson, SAP, Peoplesoft do these.  (And probably 100x better and more robust than whatever you'll implement, since it's their speciailty, and have done a dozen iterations and fine tuning)

Bella
Tuesday, March 12, 2002

I find it somewhat disturbing that a 3 year project is based on technology which is (in part) publicly available in beta form for less than a year, and (in part) not yet available at all. Despite common belief, not everything that Microsoft does is automatically successful (Anyone remember how Liquid Motion killed Flash? No? It didn't? But it was SUPPOSED to). .NET may turn out an entirely different beast than what you're thinking of now.

In your place, I'd make sure that I'm not dependent on how well .net does in the market, or whatever path it takes. A necessary condition for a predictable and controllable development process is maturity of the tools and the team's acquaintance with their working tools. I've seen too many projects delayed because of bleeding-edge tools to trust anything without 2-3 years of SOLID market experience behind it.

Ori Berger
Tuesday, March 12, 2002

Yes, I agree completely.  I'd never base a project of this scope on such a young architecture.  You're just asking for trouble, particularly with young programmers on board. Two years of your three will be spent trawling MSDN, doing Microsoft's work for them. 

Ask yourself this:  would you rather read easy answers on USENET or pull your hair out on a weekly basis, not believing that you're the first to each issue as they arrive. 

Gotta love early adopters.  Somebody's gotta do it :)

Timothy Falconer
Wednesday, March 13, 2002

Magpie programmers ("Oooooh - shiny thing!") have been a serious problem where I work.

We had one contractor here who has caused a fantastic amount of damage, and nobody in management believes or realises it yet. When I demonstrated one of his shiny COM objects was talking 45 minutes to carry out a task that took less than a second in boring old Delphi code, I got blasted with a rant about my inexperience in multi tier development etc. etc. When I showed him how to improve the performance to near the levels of the old code, he told me off for 'hacking' his code. It got to the point where I actually had to refuse to work with him to get management to take any notice of what was happening. His contract wasn't extended. But it did a lot of damage to the working relationship with the other contractors (his buddies) plus some of his code is still in use despite a huge number of flaws (because the others still think it is cool).

We have a simple suite of client-server apps that now have XML, XSLT, COM, MTS and other acronyms thrown into the mix. Deployment is trickier. Bugs are harder to track down. Maintenance is far more difficult. Debugging is harder. Where we once had simple function calls that wouldn't compile if you got a parameter wrong, we now have XML everywhere and you can compile any old rubbish because every function just takes an XML fragment (and therefore checking for validity is only possible at runtime). It's utter madness. I could go on and on, believe me.

Just one of many reasons why I've been trying to find somewhere better than this!

DB
Wednesday, March 13, 2002

> We had one contractor ...

A contractor's motives aren't exactly the same as yours, e.g. magpie experience ehances their resume for their next contract. For that and other reasons I'd be wary of letting a contractor make unsupervised architectural decisions.

Christopher Wells
Wednesday, March 13, 2002

This discussion struck a chord with me. I wish I had asked a similar questions when I faced my first big project.
People have been talking about NET being too new, what is the right tools and so on. I don’t feel the technology matters all that much. How you manage the development environment is what really matters.
I strongly believe that developers should not have root or admin access on their workstation. If a programmer finds a neat widget on the web, they should not be able to download and try it out. That sounds harsh, but when a workstation just crashes, nobody knows why, you’ll thank me. This includes the latest service pack.
Pick the tools you will use carefully, and then stick to them. Make the install close to the same for everyone. The ideal situation is when one developer has a tool problem; everyone should have the same problem. Take the Joel Test. Setup source control, backups, and all that. Take control of these things and be sure it is done and done right.
James made a good point as well. Look carefully at why you have a three-year time frame. The project is in the preliminary stage, everyone is excited, the sky is the limit, no body is asking how much money is gone and how much will be spent to finish. The whole project is new and shiny. Everyone wants to touch it.
Think about life in a year, maybe two. You’re bogged in details of design, bugs, one developer is off in the weeds and has broken a major interface, the boss wants weekly status reports, and you would like to go home before 8:00 PM today. The shine has worn off. Two developers have left and the new guy has the great new idea he is evangelizing to the group.
I am trying to scare the hell out of you. A healthy dose of fear brings out common sense. Here is my list of four pieces of advice to remember from this little rant:
Take the initiative and take control of what affects the project.
Keep the big picture in your head. If you can’t, you are not in control.
Talk to the people doing the work, do some if you can. You should know the state of every developer in your care.
Always think ahead to the next step. What is the least amount of work with the greatest benefit? How will this bite me in the ass next week? Next month?

“I went to the University of life, school of hard knocks, and kindergarten of having the shit kicked out of me” – Black Adder

Doug Withau
Wednesday, March 13, 2002

I'm not very experienced; I've had about 3 years under my belt.  But I've been able to stay away from this whole magpie problem by programming with pen and paper.  Things like XML only confuse the issue.  I mean, SQL is also brain-dead, but at least it's not far removed from relational databases.

Maybe this can help somehow. 

The most effective thing I've seen to curb magpie development is having severe size/performance constraints.  Then the interesting things become algorithms and data structures.  No one uses dumb libraries when all of them are carefully watched.  Having these constraints should satisfy the need to have craftsmanship in software dev.

I think targetting .NET can actually be a boon.  It's a hostile platform, for being so new.  Speed is no doubt atrocious, documentation probably isn't up to Java's standards, and the defects are staggering.  That'll keep them from their most magpieish fantasies.

american programmer
Wednesday, March 13, 2002

Doug Withau,

I'd quit in a heartbeat if I have no control over my dev machine.  I have a mind of my own, you know.

If you made sure that everyone had a play machine, maybe I wouldn't mind being treated with this disrespect. 

I believe you're overcompensating for not having had control over the people in your project.  Probably they were assigned to you.  But you can trust smart people to get the hint.  The nice thing about open source projects is that you don't have to accept code from people you don't trust, and you get to select who has CVS access...

a. programmer
Wednesday, March 13, 2002

Get some VMWare copies and have them run either on your machine or on a shared server. This way you can have all kinds of environments you want.
If I had used this in one of the previous projects I ran, I would have finished the job much quicker (and would have a copy of the *complete* environment on CD to bring it up in minutes).

Philippe Back
Wednesday, March 13, 2002

Developers should, indeed, have total control over their own environment (i.e., the box on their desk).  However, there also needs to be a "clean" (or "cleanable") test environment, which the developers can't muck with arbitrarily.  Developers should also be strongly encouraged to play with shiny new things.  However, introducing new things into a revenue-generating product needs to be dealt with cautiously.  There's a strong distinction there.

Any development effort that doesn't have a reliable, repeatable testing environment is following the time-honoured tradition of having their user base be their testing environment.

 

James Montebello
Wednesday, March 13, 2002

I have a few things to say on some of the topics that were brought up:

I'm definatly a 'young programmer', but i'm not always jumping on the newest buzzword, not all of us are like that ;-).  I like to stick with my perl and vb.  Recently I decided i'd pick up a language with a little more power and flexibility, and I decided to try out C#.

Despite microsoft not having the entire .NET architecture fully functioning, C# seems like a really useful tool for certain things.  Within a week I was bustin out apps that should have taken me 3 times as long to do, and they ran much faster then I expected (MUCH faster then java). 

Also, 3 years???  I don't have too much experience under my belt, but I've been part of a team (usually a couple (2-4) young guys like myself and one experienced coder/project manager) that have come out with HUGE apps in less than 3  months.  I understand that sometimes there are really large projects that are very complex, but--in three years .NET might be old news ;-).

Vincent Marquez
Thursday, March 14, 2002

*  Recent Topics

*  Fog Creek Home