A method “M” of an object “O” should invoke only the
the methods of the following kinds of objects:

1. itself
2. its parameters
3. any objects it creates/instantiates
4. its direct component objects

 Why is this a good thing? In simple terms, following the Law of Demeter, you enforce encapsulation of a method’s implementation and dependencies on other objects. Should that method have to change at a later time, it minimizes the impact on callers of the method, localizing the change to the method in question and its subordinates.

For more information, and perhaps a more succinct explanation, see the linked article above.

“I’ve seen things you people wouldn’t believe…”
 – Roy Batty, Nexus 6 Replicant, Blade Runner

I’ve seen the use of design patterns for the sake of having used a design pattern, with interfaces so generalized that types have been thrown out the window so as to refer to all parameters and return types as simply java.lang.Object. I’ve seen applications written in C++ where pointers to proper objects have been re-cast as unsigned long, totally stripping type information (and the fact that the value is a pointer), passed around and then re-cast to a (hopefully appropriate) object type elsewhere. I have seen Translator objects, written to perform translation between DTOs and general Beans meant to be consumed at the User Interface level, that also including translation from HTML form attributes to both DTOs and Beans. I’ve seen hard-coded character buffers in C/C++ applications that are easily overrun when std::string was readily available.

I have seen the Big Ball of Mud up-front and personal.

It is easy for us to sweep these, and many other, examples of poor practices under the rug and claim that these are examples of mistakes made by junior developers, and that by hiring a lot of senior developers, a company may avoid these pitfalls. Unfortunately, I can attest that many of these mistakes that I meniton above were made by some very smart and senior individuals (or groups), many of whom have looked back and wondered exactly what they were thinking. Perhaps it is lack of thinking that has lead to these missteps. Regardless, mistakes or flat-out bad architectural choices get made by very smart people every day.

Code is business. Code is money. Code can make it easier for you to make more money more easily, or it can drag your organization into the never-ending mire of constant bug fix releases. As a coder, intimately in tune with whatever code I am working on, I’d like to believe that the decision is mine on what and how to fix the code under my gentle guiding fingertips, but the reality in many software development environments is quite different. Business drives release cycles and feature sets. They have the budget which may be spent by development for certain features in a given amount of time, and for the Quality Control people to verify that everything is working correctly as per the requirements.

In this type of organization, where development is not seen as source of revenue, but as a cost center, it can be argued that if there are fixes to be made that are not congruent to the current release, they need to be made “under the radar” or as part of some manner of “skunk works”. But regardless of how many off-hour unpaid altruistic coding expeditions that you may be willing to undertake, your fixes for the code blemishes may not make it to release. If your development team’s lead is vigilant in watching commits to source control, and is code-literate enough to notice that your changes do not appear to be contributing to the officially mandated requirements, all your hard work may be for naught.

Some that I’ve talked to in the past suggest that you should engineer enough time into your estimates so that you can correct wrongs in an area of code while delivering the feature set at the same time. This can work if you have buy-in from your development lead, but more often than not, those dev leads are being watched as well.

In the end, in this manner of organization, you need to be able to raise the importance of code-craft and “making it right” to the attention of the business teams that control the budget. And that can be tough.

While the article The Big Ball of Mud does not suggest how to fix the simple issues I mention above, it does offer multiple nuggets of wisdom between the lines as to how one may approach the powers that be in order to suggest time and/or budget to be allocated to fixing the blight that may be festering in your code base. The article provides some excellent ammunition.

And, if nothing else, it is a great read that draws from a number of sources and suggests some wisdom which may allow you to avoid becoming mired in mud in your future projects.

Enter the HP ScanJet 5590. Looked good, wasn’t too expensive, was rated for light office work, I thought I had found a winner. So I ordered, received and installed the little beastie on my Dell Precision M4100. And then disappointment set in.

I managed to scan one document as a “test” that night, but since then I have not been able to scan anything. I keep getting the HP updates, and still no joy. Today I received the update to HP Solution Center 13, and with it the hope that my problems would just go away. Negative. More problems ensue.

The install seemed to go as planned, but at the end it immediately rebooted my computer. No message or confirmation message box, just boom! Now everytime I restart the machine, I spend the next 5 minutes clicking ‘Cancel’ when something called “TrayApp” repeatedly attempts to find the .msi that has been deleted from the machine’s temp directory. It seems they installed right from the temp directory, and rebooted before the “TrayApp” could completely finish installing. I am not the only poor soul that has encountered this issue, it is well covered on HP’s support forums, with little or no words of wisdom that I can find from HP themselves. The consensus seems to be “reinstall the drivers”.

This is not the only problem I’ve had with this particular suite of software. When I installed the scanner, I had hooked it to a USB port on the back of the laptop. When I finally moved the scanner into my office, I hooked it to the back of my docking station. The HP software proceeded to recognize it as “HP ScanJet 5590 #2“. Excellent. I removed the #2 device in Device Manager and hooked the scanner up to another USB port on the laptop itself and got the same result. Apparently, the drivers are sticky with respect to the particular USB port on which the scanner is installed.

When I decided to ignore this little annoyance and  perform a scan, sometimes the scanning would appear to hang, other times I would get a message on the screen telling me there were some kind of communications issues with the device.

I have had relatively good experiences with HP’s equipment in the past, and the scanner itself looks to be fairly well made, but I have to take issue with HP’s drivers and/or applications. Currently, I am uninstalling all the HP drivers and apps on my M4100, and I’m going to attempt to re-install using a full-setup I downloaded from HP. Will this solve my problems and renew my faith in HP?

More news later…

…and my website is non-existent.

So, like many others on the ‘net, I resort to WordPress. Check back in the near future, I promise to have better content than this.