Stop programming like the architects of Star Wars - the same idiots who failed to put up guardrails around bottomless pits.
From the "Just Last Week" files:
I found out that a very bright developer wrote code made the bad mistake of thinking that he would always be the only developer in charge of his code. He wrote multithreaded code that did not protect a very useful, method-laden collection of data from simultaneous access by 2 or more threads. His rationale was that he would, by convention, only access the dataspace from the main thread. Then he had the gall to get transferred away from the development group, and The Ninja got his code. And promptly found there were several cases of a secondary thread accessing the dataspace, the unprotected dataspace, at the same time as the main thread was modifying it. The predictable result was a program crash.
You cannot ever expect the developers who follow you to know or remember all the little rules you've set up for your own little code kingdom. You ignore the Best Practices at your own peril. If you are working in a multi-threaded process, you must assume that all threads may access a global data structure, and if it gets modified, those accessing the data will crash. Assuming that the next guy will not tromp on your daisies is foolish.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, November 21, 2007
Too Much Information
I'm all for the freedom of information, among individuals. In the corporate world, there are sometimes
good reasons not to tell someone part of the story.
Case in point (with serial numbers filed off) - a discussion last week touched upon an old release, where there was a big improvement in performance, brought about when a developer found an inefficiency in transaction processing, removed it. In the process of this release, upper management was pressing for a rationale, and someone offered a detailed explanation of the issue, using the names of the various classes in the code. Because some of the class names were chosen for their purpose in the code, they had a rather ironic connotation in the situation. This led to essentially a disparaging attitude towards the development team in upper management, which is never good, because then the expertise of the developers in their field is undermined.
The Ninja Solution(tm) is to implement a Gaussian blur for the information when talking to upper management (anyone higher up than your immediate superior). Never mention class names to them. Never describe the algorithms by the code names - blur out that level of detail. This prevents the bosses from finding humor in their misunderstandings of the code flows.
Note that this is not a license to lie to them - just to tweak the level of detail you use to report upwards (and sideways - program managers don't need to know class names either.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
good reasons not to tell someone part of the story.
Case in point (with serial numbers filed off) - a discussion last week touched upon an old release, where there was a big improvement in performance, brought about when a developer found an inefficiency in transaction processing, removed it. In the process of this release, upper management was pressing for a rationale, and someone offered a detailed explanation of the issue, using the names of the various classes in the code. Because some of the class names were chosen for their purpose in the code, they had a rather ironic connotation in the situation. This led to essentially a disparaging attitude towards the development team in upper management, which is never good, because then the expertise of the developers in their field is undermined.
The Ninja Solution(tm) is to implement a Gaussian blur for the information when talking to upper management (anyone higher up than your immediate superior). Never mention class names to them. Never describe the algorithms by the code names - blur out that level of detail. This prevents the bosses from finding humor in their misunderstandings of the code flows.
Note that this is not a license to lie to them - just to tweak the level of detail you use to report upwards (and sideways - program managers don't need to know class names either.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)