I'm sure many of us have written a program or process that once completed is much larger then we first envisioned. Often that's normal because as we write the code, we gather information about the process that we didn't have during the design phase.
End users also tend to "remember" important information after they start using the new process we created. To compensate for that new information, we modify the process we first designed. Again, that is normal during development and/or the testing cycle.
Those changes begin to cause problems if the original design made assumptions or it has constraints that conflict with the changes required. It's easy to then modify other programs to compensate for the new changes. But that then can further impact things down the line. You can see the downhill cycle I am alluding to, in which the program has "grown" well beyond the design and has become "organic" in nature.
Before you start writing code, ask questions about the process. Ask what information is important and why. As programmers we have a unique opportunity to learn about accounts receivable, production, operations or whatever the task involves. We can learn about the company we work for in ways few others in the organization can. That information gathering process can determine if the design is solid. It can also tell us what constraints we may encounter.
Organic processes are hard to see if you always keep your head down trying to solve a problem. If things look too easy, they probably are. Take some time and step back to see the overall process. It may take longer to solve the problem, but in many cases you can assure yourself the problem is resolved. You won't have to deal with repercussions later on.
Ask yourself some basic questions: Is the process too complicated? Are there more programs then what should be needed to solve the problem? Is the cost of the solution greater then the problem? Can the process be maintained easily?
As the year draws to an end and the holidays are upon us, take some time to reflect on the successes you had and the projects that could have been better. Remember, as with any tip, take this information and apply your experiences and shop standards to maximize the effectiveness. A good friend once told me "that the best programs I ever wrote were the ones I refused to write."
About the author: John Kohan is a senior programmer analyst at CT Codeworks. He is also an adjunct instructor teaching AS/400 classes at his local state collage. As one of search400's site expert John also participates in our Ask the Expert feature. If you have a question for him, you may submit it.
- The Best Web Links on Development: Tips, tutorials and more.
- Ask your programmer questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our programmer gurus are waiting to answer your technical questions.
- What do you think of this tip? Send us your comments -- good or bad -- at email@example.com