Early List of Things to Remember for Software Development
I have been doing some cleaning and moving around of furniture and as a result I ran across a list I probably wrote some 15-20 years ago, of things to remember for software development. Considering that I had a lot less experience at the time, I was mildly impressed with what I had written up so many years ago, so I decided I’d share my writing with the world, for what it’s worth. And remember, this was written before XP, Agile, iterative development, and a lot of other methodologies, er, at least before I knew of them. Without further ado, here is my list, as originally written, with as little editing as possible. I may do a followup on this piece with my views from some 20 years later. I can see a few areas where I would add in footnotes or modify the wording a bit, but that’s for a later time.
- Get a general design down
- If possible, develop prototype first to find out what you like and how the system really works.
- Have at least one person who knows the hardware and utilities well on development team
- Keep group small
- Keep development unit separate from integration unit if more than 1 person working on project
- Treat globals like gotos: use as little as possible and treat them like a poor relation; you don’t talk to them, touch them or invite them over unless absolutely and positively unavoidable
- Keep the links between each module down to as few as possible, global var5iables do count as links
- Put someone in charge who word is final.Limit the number of programmer’s on a module. Too many leads to too much, too many meetings and not enough work done. Software by committee just doesn’t work!
- Write down the standards for a project before starting. Keep them as simple as possible so your programmers are allowed some creativity. Software is still more an art than a science
- If you’re the manger, team lead, grand poobah or whatever the title is, then lead! Don’t try to keep your hands on everything and control every part of development. That’s what you hired all of those programmers for. Set up a plan and help the new people on a project find the level. Leave the ones who know what they’re doing alone unless you’re not meeting the schedule or requirements.
- If you’re not leading the project than don’t try to. Give your leader what he/she needs and/or wants when she/he wants it. If there is a problem, tell him/her. If there’s still a problem, you have two choices, shut up and follow or quit
- Have a person maintain the documentation for a system and new knowledge. Get someone who likes to share
- If you feel obligated to change the interface on an existing system ask those who know and use the system. You don’t have to use their input but it may be helpful and lift morale.
- Treat your staff like professionals. They aren’t errant children to correct and watch over nor are they hired hands/bought slaves that can be lorded over. They are people who are doing their job, as best they can and they can make mistakes. Don’t make them feel like idiots for making mistakes because that’s how we learnYou are good at something when you don’t need to learn, thus when you’re not good you’re learning and prone to mistakes
- Overworking people continuously for “increased productivity” is a mistake.
- At a crisis you find out how good your organization is. If it falls apart and becomes a circus you haven’t set up your organization well enough so that people know what needs to be done. An organization under fire should operate in the same way as one with a leisurely schedule. The only difference will be in the schedules and intensity.
