I cannot stress enough the importance of not writing code. Relatively speaking, writing the code is a very small part of implementing a solution to any problem, whether it's new product, adding functionality, or debugging.
The first step is always understanding the problem. In the case of new work, that means understanding the requirement, and understanding the person who proposed the new functionality, the client, or other recipient of the finished product. If you don't do that, then there's no point going into ecstasies of UML in describing a solution. It's wasted effort.
Good requirements lead to test first development, which means writing (which may look like coding, but really isn't) good tests to fail, and getting those right such that they cover the solution space.
Then you can think about designing the code solution that will satisfy those requirements and fit into the overall architecture, following design rules, coding standards, etc. This must be documented. If you can't write about it, then it's not worth implementing. Just the act of writing, or discussing it with someone else, usually opens up new vistas of thinking about the problem.
Now you can code it (and improve the tests).
Testing of that solution has to take some time, too - and it's not a hit-and-miss process of running the debugger to step through each line, make changes, start again. Each time something goes wrong, go back & work out where it went wrong - in the design of the solution, the overall architecture, the understanding of the requirements, ...
Maintenance is the same, except that you have a different start point - the problem is that a requirement is not being fulfilled; tests are not correct (they hadn't found the problem). Therefore, the code is wrong.
Caught you! The code isn't wrong yet. The requirements were not understood, the architecture was inappropriate, the design was incorrect, the documentation is not sufficient. The implementation is again a minor detail.
I'm sure I mentioned coding in there somewhere. It was a small thing. Anyone can code, with the right training. It takes experience, skill, & intelligence to produce solutions to problems.
Software developers - the craftsmen, the artists, the engineers of the industry, happen to be able to code. It is not necessarily their job.
Developers should be able to ask questions, discuss, argue (in the Greek sense, not street sense), draw, write (whole sentences & paragraphs), think, and love their work.
Anything less is a drone.
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment