Mark’s Site

Some call it coding preparation, others will call it planning and design, but we’re talking about the same thing. The more I code, the more I see professional programmers who just want to code. They don’t care if the design is complete. After all, they have enough info to get started right? They have the coding bug. I know because I have the same bug. Coding is our high. Solving small or large problems in code form gives us a buzz. You are God of the moment. Just like any other high, it can entice you into doing something too quickly without thinking it through.

The problems come when you leave the small problems and move into medium-large scale problems with lots of interrelated subsystems all talking to each other. Or, more importantly, when you have a system with base classes and you start the coding of the base classes too quickly. End result - disaster! Coding is just like real world construction: If your foundations are crap, guess what? The final product (if you ever make it to a final product) will be flimsy at best. It (your application) will either fall over or will be subject to criticism for the rest of its short life because of what we call incomplete coding preparation.

Still feel like rushing into that programming? If you do you’re a knob (politically correct term for you morons that are giving programmers a bad name by jumping into programming too quickly, then blaming the designers and everyone else when things go to shit)

Being what I consider a good programmer means having the ability to read design documents and being critical of them. Don’t take the attitude that if the coding screws up, we can trace it to the design documents, so the designers will be to blame, not me. That’s the quickest way to failure. Instead, stand up, approach the designers and tell them of the errors or any questions you have. Feel unsure about a section of the design? Ask them! Think of it like this: If you, a professional programmer, cannot understand the design document, then the design is flawed.

A key concept you need to understand early in your programming life is that the overall goal of planning and design is to reduce risk. Asking questions of the design, if you (the programmer) don’t understand something, is all helping to minimise the risk and ensure the project’s success. Your project’s preparation needs to focus heavily on improving the planning and design so that the clear direction follows through to the programming stage. Ensuring good communication between design and programming is imperative to your project’s success and the wellbeing of everyone involved.

I know, I know, some programmers are out there reading this and saying to themselves “but my boss wants things done quickly and we don’t have the time.” Bad attitude and wrong decision.

Firstly, good design might be hard to master at first, but once your designers get in the groove of turning out quality well thought out designs, everything runs smoothly. The programmers can’t stuff anything up if the design is bulletproof, and if they do, they need a boot up the arse so they begin to follow the good direction of the design to a tee. What follows is a well oiled application making group of individuals that respect each others work and produce good results, which in turn gives the company a better reputation for quality work. The point is, good design may take time, but it takes less time than bad design stuffing up the programming stage, which will end up taking a LOT more time to fix and re-test. So if your boss doesn’t understand that, request a meeting and let them know, and if nothing changes, find a new boss because you deserve better