Documenting and getting approval before starting to code?

Question

Recently our boss changed our method of working to first document stuff such as what we are going to code, how will it affect the system code, where would i require to make changes, etc, get it approved and then start the coding process.

I believe that while sometimes its better to plan out stuff and visualize things (especially for complicated changes), mostly of the times, its a lot better to directly code into the app and face real scenarios instead of theorizing.

Is my belief right in this case ?

Answer 1

That would depend almost entirely on why your boss enacted this policy. If it's because you are a bunch of cowboys who push buggy code out to production with no sense of what that means to the user (and the reputation of your company), your boss is probably right.

If it's because some six-sigma type bod has come in and told your boss it's the right way to do things, I'd be circumspect.

As always, it depends on the circumstances (and you haven't really told us the whole picture). In any case, a couple of decade's experience has taught me that there are always ways around arbitrary limitations if you're clever enough :-)

Case in point: while we're not allowed to code new functionality without funding, we can (as a lab-type environment) put together a PoC (proof-of-concept) on our own dime, and then find that it's remarkably easy to get that to a production-quality solution.

Answer 2

I have my reservations about requiring an approval process for this, but what you're describing sounds a lot like a Solution Architecture Document.

I don't think the boss is out of line for requesting this as long as the level of detail is broad and generic. Mapping out how and where you're going to implement a solution, along with demonstrating that you've put thought into different possible approaches to the problem is arguably good practice - especially in larger systems.

In essence, it demonstrates that you've done due diligence and put some thought and effort into finding the best possible solution to the business problem.

Answer 3

I'd have to go with your boss on this one. You really should know the answers to:

• What (basically) am I going to code?
• Why am I writing this code?
• What risks are involved in writing this code?

If you can't answer these questions, the odds are pretty good that you will

• have to try several times to get the code that addresses the problem
• write unnecessary code
• break something

Also, answering these questions will enable you to write the tests needed for the new code. You do write tests, right?