Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Maxims for Programmers

by perrin (Chancellor)
on May 18, 2002 at 17:58 UTC ( [id://167537]=perlmeditation: print w/replies, xml ) Need Help??

Over the years, I've discovered a number of truths about programming and the way programmers interact with others in their jobs. These have evolved into a sort of mini-philosophy, and I thought I would share a few of the more interesting ones here. Here they are, in no particular order:

Good programmers don't require much project management. No amount of project management will make bad programmers good.

You will never get exact and complete requirements, and even if you did, they would change by the time the project was complete. Your only hope is to plan for changes and talk to your users.

Commercial application frameworks (e.g. application servers) never do quite what you need them to do, and you can't change them to meet your needs because you don't have the source.

No amount of documentation is a good enough substitute for the source code.

Management assumes that the programmers at the company trying to sell you an application framework must be better than the ones at your company.

SQL is very high-level and easy to write. Be very wary of people who try to save you from "hand-coded" SQL by giving you some huge proprietary API to use.

New technologies rarely are. The problem you're working on now has been solved at least a thousand times before, and probably at least a decade ago.

There are very few problems that are best solved by a distributed object system.

One good programmer is more useful than many not-so-good ones. Hiring a bunch of not-so-good ones will slow down the good ones.

The performance bottleneck for most web applications is the database. If that isn't the case with yours, you're probably doing something wrong.

Choice of algorithm has a much greater effect on performance than choice of language does.

Your sloppy, ugly, unmaintainable code is not Perl's fault!

Replies are listed 'Best First'.
Re: Maxims for Programmers
by samtregar (Abbot) on May 18, 2002 at 18:32 UTC
    Good programmers don't require much project management.

    I guess that depends on your definition of a good programmer, doesn't it? If your definition includes "doesn't require much management" then I guess you're right. But I've seen many programers that were doubtlessly "good" at the core tasks of programming but still needed lots of oversight to stay on task.

    You will never get exact and complete requirements, and even if you did, they would change by the time the project was complete. Your only hope is to plan for changes and talk to your users.

    I'd take that a step further - exact and complete requirements do not exist. Resist the urge to pretend your failures were the result of not being given them.

    -sam

      That's true, I generally think of good programmers as people who are able to take the larger goals and schedules into account and manage their own time appropriately, e.g. not design a huge academically perfect solution when the project needs to be done in a couple of days and a simple approach will meet the immediate need. That proejct management one is a reaction to the idea that a not-too-bright person with no technical background and a copy of Microsoft Project is somehow needed to keep projects on track. Most of the companies I've worked for seem determined to foist one of these people on me whenever we have a project that lasts longer than 10 minutes. I always end up doing the real project management (negotiating requirements, prioritizing features with users, tailoring technical approaches to meet the expected timeline, coordinating with the other programmers) myself, because these so-called project managers are not capable of doing it.

      The thing that gets me is how they always want a big sequential list of every "task" so that they can enter it in Microsoft Project and tick things off. Lists like that create an artificial notion of accomplishment, i.e. finishing a small zero-risk task and checking it off looks more important than making progress on a large and risky task. I could go on bitching about the cult of Microsoft Project for pages, but I'm sure we've all been there.

        I could go on bitching about the cult of Microsoft Project for pages, but I'm sure we've all been there.
        Word brother... those gantt schemas must die...
        You have moved into a dark place.
        It is pitch black. You are likely to be eaten by a grue.
        Whenever I hear someone using the word 'deliverable' as a noun, I reach for my gun.

        If only.

        Same goes for anyone who refers to a human being as a 'resource'.

      Most reasonably-okay to good programmers don't require much management for the project they're working on, you're right-the management needed is more often on the order of running interference to keep small, numerous, and often unconnected (to the project in question) distractions from eating away at the programmer's time.

      As to complete and exact requirements, these are mythological creatures. In this case, the project management needed will be someone to enforce saying they had their chance to add that into the current requirements when it is said, "This is what you will need, right? You're absolutely sure?" and they say, "Yes," then try to come back a week or more later and say, "oh, by the way, we also need it to do...."

      (Well, we can hope, can't we...?)

Re: Maxims for Programmers
by Elian (Parson) on May 18, 2002 at 22:48 UTC
    No amount of documentation is a good enough substitute for the source code.
    And no amount of source code is a good enough substitute for the documentation.
      Thanks, I like that one!
Re: Maxims for Programmers
by cjf (Parson) on May 18, 2002 at 21:12 UTC
    Good programmers don't require much project management. No amount of project management will make bad programmers good.

    So who are these mythical "Good" and "Bad" programmers? I don't think I've ever met either type. I've seen certain programmers write very low-quality, buggy, insecure, and all around ugly pieces of code before. I've also seen the same programmers turn around and produce extremely solid code the next day.

    Were these programmers magically transformed from "Bad programmers" to "Good programmers" overnight? No, they finished working on a poorly defined Big Ball of Mud yesterday and started a well defined project with a knowledgeable manager the next day.

    Good project management may not transform a programmer overnight, but it definately can help produce better end results and teach good programming practices at the same time.

      Good project management may not transform a programmer overnight, but it definately can help produce better end results and teach good programming habits at the same time.

      I agree with you. Learning how to manage one's programs effectively is an art. What "years of programming practices" cannot teach, a simple lesson in project management can do. It's may be apperant that no project management is required for very small projects. If you look at it again, the idea of the project management running in the background in your mind can definitely help.

      Making list of your resources, taking inventory of your skills etc, has power to help you when you have lapse of memory, time etc.. Extending further, if you further identify these things for each and every programming task, it can become a very good practice and ultimately help you to finish your task faster and more effectively. Inititally you will feel a time waste, than it will run in the background and these skills will be woven in your mind, just like basic perl functions.

      Artist's point of view

      Were these programmers magically transformed from "Bad programmers" to "Good programmers" overnight?

      Er... no, they're still the bad programmers. Bad programmers can write good code. They just require much, much more handholding. And a project manager can't do that handholding; it has to be a good programmer. (Note that a great project manager can fill in that role -- if he happens to be a good programmer.)

      I'm not saying project management is useless. In fact, it's critical. But I fully agree with the original quote -- it's not enough by itself, and much, much less of it is needed if you have good programmers in the first place. Which isn't saying much, because part of what makes a programmer good is being able to do a part of the project management.

      It is certainly possible to create a decent product with a team of bad programmers and a good project manager. I've seen it done. And I've seen two good programmers get fed up with the pointless lack of flexibility and maintainability, and rewrite the whole thing in less time and produce a far better product. Admittedly, they gained from the experience of the first implementation, but they didn't stop there -- by the time they finished, the product had at least twice the functionality of the original (it was being sold in parallel, so new requirements were pouring in.) And it was still easier to maintain and extend, and there still wasn't a product manager involved. Sure, it's anecdotal, and there were some near-disasters that could have been avoided with better project management, but it still supports the original claim.

      Good programmers will steer clear of mudball maintenance jobs given any choice at all..

      Makeshifts last the longest.

        Great programmers can turn the big ball of mud into something maintainable. (Though it does take good management to run interference...)

        Ah, I see now...

        "Good programmers" eq "Unemployed programmers" ;-)

        Update: Big Ball of Mud related node linkage - Failure To Refactor.

Re: Maxims for Programmers
by Maclir (Curate) on May 19, 2002 at 02:35 UTC
    Good programmers don't require much project management. No amount of project management will make bad programmers good.

    Do you really know what project management involves? Do you think all a project manager does is use Microsoft Project to churn out fantasy gantt charts and schedule endless meetings that disrupt your real job of writing code?

    I suggest the first thing for you (and all others who complain about project managers obstructing the "real work" is to read a copy of the Project Management Institute's "A Guide to the Project Management Body of Knowledge". Use Google to find the online pdf version.

    Okay, do you have your copy in front of you now? Section II covers the nine project management "knowledge areas". The first stage, "Project Integration Management" covers the development of a project plan - note that a project plan is more that just a gantt chart. Some other responsibilities of the project manager are:

    • Scope Management - Defining the project scope and deliverables; dividing that into smaller, manageable components; formal acceptance of the scope and change control. Hmmm - why do some projects fail? No scope management.
    • Quality Management - regularly making sure that the deliverables will be achieved. Quality control. Les not wait until the system goes into production before we find it doesn't work, ok?
    • Risk Management - what risks are likely to impact the project, what is our response to each of these. When should be "pull the plug" if it is clear the project cannot deliver.

    A good programmer knows how to best translate specifications into a working application (computer code, database structure, etc). A good analyst knows how to translate the users requirements / dreams / fancies into realistic, achieveable specifications. The project manager coordinates all of these - plus keeps management and users involved without obstructing the work of analysts, programmers and other project team members. All of these are specialised skills, and are equally critical to the success of all (non-trivial) development projects.

    So, lets assume you are a good programmer, and you have been given a role as the lead programmer in a project. You still need a good project manager to perform all of the necessary project management tasks - to ensure you have specifications that are clear and realistic, to make sure that you are not distracted by non-essential changes every day or two, to make sure management and users know the project progress and status.

    If you are a bad programmer, a good project manager will not make you a good programmer. A good project manager will make sure you are not a part of the project. (<monty>This is an ex-programmer. He has shuffled of this mortal coil, and joined the choir eternal.</monty>)

      It's interesting that this particular one seems to have generated the most reponse. When I wrote it, I had something pretty simple in mind. I didn't mean that projects should not be managed at all, but rather that most of the "project manager" people I've worked with are not very helpful. Nearly all of them were basically incapable of doing more than acting as glorified secretaries. They can't manage scope because they don't understand the work or the impact of changes and additions. They can't manage quality because they can only see and understand a small part of the system. (These are the people who are quick to e-mail you when an image is the wrong size, but have no idea when the entire application architecture stinks.) They can't manage risks because they don't know what's risky. They are handy for setting up meetings when the programmers and the cusotomers need to talk about these things, but that's about as far as it goes.

      There have been a few significant exceptions to this rule over the years, and my heartfelt thanks go out to those people. If only there were more.

      You brought up ideas about analysts and managers as well, but I won't get into that because I wasn't commenting on them in my statement.

Re: Maxims for Programmers
by mem (Acolyte) on May 19, 2002 at 09:35 UTC
    No amount of documentation is a good enough substitute for the source code.

    Pet peeve alert! That's true, but undocumented source code is as bad. I don't mean stuff like my $count; # particle hit count, but design documentation. I've dove into undocumented source code too many times, extracting flow control diagrams, drawing data structures, documenting program logic in general. It's hard and it's tedious. A design document belongs in the source code. It's not enough if there's a dead tree version filed away on someone's desk. It has to be right there, with the source code. Very few large projects have good design docs because programmers hate writing documentation. They try to get away with arguments like yours, which is ok for the person who wrote the program, but extremely painful for the people who show up later.

Re: Maxims for Programmers
by VSarkiss (Monsignor) on May 19, 2002 at 02:49 UTC

    I say this a lot, but sadly, few co-workers "get it":

    It's better to get the right answer slowly than the wrong answer quickly.
    Anyone who's ever optimized correctness away knows what I'm talking about. ;-)

      That's a rather controversial statement these days... ("Worse is better", etc.)

      Personally, I agree with you in theory. However, in practice, a shoddy but shipping product today is better than a perfectly-designed and implemented product that is only half done when your funding runs dry.

      (Rereading your wording, I suspect that you may mean "answer" as in "the output of a program", rather than the program itself, but even then a 90% solution may be adequate, provided that it's smart enough to tell you when it can't work out the correct result.)

Maxims for Managers
by pdcawley (Hermit) on May 20, 2002 at 08:34 UTC
    The job of a manager is/should:
    1. To assemble the best team of programmers possible.
    2. To point them all in the right direction.
    3. To keep them all pointed in the right direction (by clarifying requirements, supplying new ones, generally tracking performance). This is a continuing process and is probably the most important duty of a manager.
    4. To give them the tools so they can finish the job.
    5. To get the hell out of the way.
    The best managers are one of the team. They are doing a different job from the programmers but their contribution is palpable and their presence is appreciated.

    Bad managers are resented. They seem to spend all their time getting in the way. They are, and they hire, dead weight. If you get stuck with one of these and you can't train it, then get the hell out of Dodge, you're doing yourself no favours.

Re: Maxims for Programmers
by sfink (Deacon) on May 20, 2002 at 20:18 UTC
    New technologies rarely are. The problem you're working on now has been solved at least a thousand times before, and probably at least a decade ago.

    If the problem is particularly tricky or interesting, then it was solved at least 40 years ago, probably without having a computer around to try it out on.

    I especially notice this in hardware. These fancy out-of-order execution engines? Speculative execution? From the 60's. It's odd how the balance between different variables shifts back and forth. Solutions from a few years ago make no sense with (eg) the relative latency of today's memory and disk accesses, so people reinvent the solutions from the previous generation instead.

    Hmm... is this similar to human relations? "Yeah, Dad's pretty lame, but my grandpa is cool!"

Re: Maxims for Programmers
by beretboy (Chaplain) on May 19, 2002 at 16:18 UTC
    Amen and hallelujah!

    "Sanity is the playground of the unimaginative" -Unknown

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://167537]
Approved by BazB
Front-paged by grep
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2024-03-28 13:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found