To Buy or Not to Buy Technical Books, That is the Question

So the rookie coder is working at his new job, fresh out of college, when the team malcontent is overheard a couple of cubes over, "This place is so cheap! They should reimburse me for this technical book. It's a heckuva lot cheaper then a training class."  However true that is, it hides a simple choice: keep the book and be out the money, or give up the book and pocket the cash - assuming the boss will foot the bill.

Recently a question on Stackoverflow reminded me of that rookie coder. Being fresh out of college gives you an amazing combination of overconfidence and cluelessness.  Without any basis, it's easy to take the office attitude and run with it.  You shouldn't have to buy your tools, your company should.

I disagree.

Why? Because they are tools. It's not even a cost thing. A professional should be responsible for knowing which tools they need to be most productive. Tour an airline maintenance facility and check out the workshop.  A large area, maybe 1000 sq. ft., with nothing but large toolboxes;  each with a name and a lock. The mechanics have to buy all their own tools, think wrench sets and so forth - not large things like engine dollies.

At first it seems a bit silly and redundant but when you start to think about it, it's easy to see that not everyone is going to want to spend the extra money on the high-end tools, or they might want extras of the same set for whatever reason. Also, consider the hassles with sharing, e.g. "Where are the 1/2 inch box-end wrenches?" By not making the tools shared, the 'Tragedy of the commons' is avoided.

Another example is chefs and their knives. You don't touch another chef's knives. The restaurant provides the big things like ovens and stoves, the chefs bring their own knives.

Back in the world of computers, I've brought in extra memory before. I told my manager so he'd know that some of my personal property was in the PC in case it needed to be worked on by the internal techs. I also put a note on the box itself. I would have had a bigger issue if they discouraged bringing your own hardware. Most shops like to provide the box itself because it minimizes their support issues but they shouldn't have any problems with you bringing accessories like monitors, keyboards, mice, etc.

To summarize, change how you think about tools and strive to use whatever makes you better at your job, even if you have to pay for them out of your own pocket. It's the 'Professional" thing to do.

Tower of Babbling

When I started coding at my first job almost 20 years ago, it was at an OS/2 shop using C and Presentation Manager. I had several different languages in college so I wasn't too phased by the 1-2 week C training course we got. What I wasn't prepared for was memory management, C style string handling, message-driven applications, just to name a few.

I began my dislike of C early with the insanity called string handling. I was pleased when I found out that Joel agrees with me. Although there are plenty of people who will defend how 'intuitive' the string functions are, I knew there were much simpler ways to manipulate strings as long as you didn't need one larger than 255 characters, in which case using a char* buffer would be fine. Writing apps in something other than C was dismissed offhand with statements like, "C is much closer to the metal", "You don't have the run-time bloat of other languages", or "You have so much more control with C" which almost sounds like a masculinity test or something. Think lumberjacks and "my chainsaw is bigger so only the strongest can use it" type argument. Nowadays, this type of behavior would remind me of The Code Monkey.

Even 2 decades ago, it was possible to call code written in one language to call code written in another; in school we called assembly graphics routines from within Ada code for one class assignment. Notable exceptions are running compiled code from within scripts or executing a system command from within compiled code; but rarely do we write a library in C++ to use in our Java app. When Java first appeared and it was still slow, I never understood the resistance to writing the main app in Java and moving the bottleneck code into some C/C++ dll and called using JNI. It's like we use the "language X sucks at a, b, and c so we can't use it" as a shield that keeps us from having to design multi-language applications.

So, after all these years, what keeps us from writing multi-language apps?

Where do you go from here, and where is here exactly?

Developers have a love / hate relationship with version control systems. A related post is this one on 'Scar Tissue'. On one hand they either don't do something you desperately need regardless or any pleading or begging. On the other hand they do something that 'conveniently' adds to your workload and refuses to have it any other way. However maddening a VCS can be, software development would be a nightmare without one. Most shops have a preferred tool which is a polite way of saying "Use it or else!" That being said, developers typically learn to use the preferred tool and leave the administration to someone else.

Installing a VCS for my personal work has been on my todo list for a while now but always got pushed onto the back-burner. In the past I've actually worked in a serious development shop that didn't have any versioning system for the first few years I was there. They didn't collaborate much or have the need for branching and since it was my first gig out of college it didn't have that "working without a net" feeling that it would these days. That shop did finally move to Sorcerer's Apprentice before it was bought by black-hole of software known as Borland. After that was PVCS which was expertly configured and taught me a great deal about the benefits of a rationally conceived and executed version control system. Using promotion groups in an orderly way to move code changes along a path from 'only-seen-by-me' to 'ready-for-final-testing' was an arrangement that I wouldn't see again. From there was Visual Source Safe which was serviceable, which means I wasn't the admin, but wasn't very robust. Then there was RCS/CVS which work better than nothing but still leave something to be desired. At this point I realized that the thing I was searching for was not to be found in a tool but in the common understanding of a group of developers who share a development environment and work together to get the most out of the VCS and make each others jobs easier. There is a lot to be said for sitting down as a development team and hashing out a commonly understood development model.


Where am I going with all this? The company for which I work has a policy of buy over build which was served them well for the last 10 years. They've kept their IT costs down while still getting applications deployed for their internal customers. The vendor was trying to write applications it could turn around and sell to other companies in the same market and my employers got a discount on the work; everyone was happy. This arrangement went south when the development partner decided to get out of the business of writing and selling software. They parted ways without rancor but now my company is left with application code for which they have no experience in managing. That's where I come in, to help them with managing software, to advise them when vendors try to close a sale with marketing smoke and mirrors, and to detect when those vendors could be hiding important details about their product or service.

So, I ask for the code and am given a large ZIP file, I kid you not. Evidently the off-shore group of the development shop used by the vendor uses Visual Source Safe locally but it isn't used by anyone here in my office. That led to another nightmare when I researched how code was deployed to production but I'll save that story for another time. I've used VSS before but since most of the code is Java and we're not using Visual Studio, it didn't make sense to use VSS. After poking around on the Internet, I found some really good reasons not to use VSS. Evidence about corrupted databases, well documented issues, and stories from the trenches made it easy to decide to use some other tool.

My first thought was to install Subversion so I downloaded it at home and started learning how to manage a repository. Someone at work mentions a new VCS called 'Git' which is fairly new on the scene, so when I checked it out (there I go again) and at first figured we didn't need the multiple author patch model, where a change has an author and a submitter which is useful for accepting patches through email. After more thought the realization came that the strength of the tools like PVCS or IBM's Rational Clearcase were that they understood branches even if you didn't use them all that much. Subversion doesn't have a great track record with branching. Since the budget was tight that means sticking to free products which came down to Subversion or Git. I'm leaning towards Git.

Off into the wild blue yonder I go. If anyone has stories and/or advice on setting up a VCS for the first time, I'm all ears.

Who Is Your Mother-In-Law?

If you were to describe the dependencies of your application, would they look like a family tree? Do you know all the services on which you depend and if so, to what depth?

Have you ever had your application fail because a service it uses is unavailable? Sure, but what about if that service uses a service that goes down? We've always done a poor job of tracking who owns which app, not to mention which apps depend on which other apps or services.

If we used make tools like nmake or ANT, we could describe each component as a target and include each targets dependencies and then let the tool tell use the extended family tree.

As a bonus the support of this distributed environment becomes much easier. If we update a given component, we can let the tool figure out which apps need to be notified of the outage/upgrade/etc.


Your better half (the UI) has it's mother-in-law come for a visit ( a legacy app wrapped as a service). Does that make indirect services into cousins?

Stalking a Serial Thinker

Some people think using groups of lists (1 dimensional) , others can think in grids (2 dimensional). I ran across this phenomenon when I was in a requirements gathering session for a complex revenue accounting system. Many of the components of the system had several attributes in common. The example I'll use is a family of four (Mom, Dad, little Gary, little Jan) and their bicycles. One way to describe the bikes is list each of the separately by the owner and then their attributes. For a serial thinker (let's call them Serial Sue), it looks like this:

Bike1
Owner: Mom
Type: Touring
Gears: 15
Size: 26-inch
Color: blue
Make: Trek
Model: Super-Safe Sidewalk
Wheels: street
Accessories: water bottle

Bike2
Owner: Dad
Type: Hybrid
Gears: 18
Size: 28-inch
Color: black
Make: Specialized
Model: Trail-aways
Wheels: knobby
Accessories: speedometer

Bike3
Owner: Gary
Type: Mountain
Gears: 24
Size: 26-inch
Color: red
Make: Specialized
Model: Porche
Wheels: knobby
Accessories: rear view mirror

Bike4
Owner: Jan
Type: learning
Gears: 0
Size: 16-inch
Color: yellow
Make: Murray
Model: Princess
Wheels: street
Accessories: handlebar tassels


Notice how each bike repeated all the attribute names? No big deal right? What if you now need to add 2 more attributes to each bike, or 4, or 10? You would have a lot of editing in your future.

Don't get ahead of me here but another way to organize this data is with a grid (aka a spreadsheet) which could look like this:

	Bike4	Bike3	Bike2	Bike1
Owner	Jan	Gary	Dad	Mom
Type	learning	Mountain	Hybrid	Touring
Gears	0	24	18	15
Size	16-inch	26-inch	28-inch	26-inch
Color	yellow	black	red	blue
Make	Murray	Specialized	Specialized	Trek
Model	Princess	Peaks-r-us	Trail-aways	Super-Safe Sidewalk
Wheels	street	knobby	knobby	street
Accessories	handlebar tassels	none	speedometer	water bottle

In this form it becomes easy to add categories and/or bikes; thus maintaining the list in an efficient manner. The problem? Describing this method to a Serial-Sue will confuse them. They'll ask, "Why go to the trouble of creating a grid, all I want is a list?" You might think that it is a simple matter of just do it they way your boss wants. That is fair but there is more to the story. When dealing with a large list of semi-related things, using categories to subdivide the items can be an enormous help in simplifying the organization and can help bring order out of the chaos.

Another clue you are dealing with a serial thinker is if you show her a grid and then have to explain it. It takes a different sort of brain. Much like how some people can't read maps well, go figure. Watch for symptoms of frustration when showing or explaining a grid of data to someone, it could be that you've botched your data, but it could also be a sign of serial thinking.

So, do you work for/with a Serial-Sue?

Or Else What?

So, I'm about to do some development on a project that will be using IBM's RAD7. In prepration, the developers are going to a RAD7 class. During class the instructor is dutifully showing us all the bells and whistles and he does this:

if ( somecondition)
{
return success;
}
else
{
return failure;
}

I thought I'd exhert some independence and remove the else block:

if ( somecondition )
{
return success;
}

return failure;

My code is equivalent to the previous example but I began to wonder how do you know when the 'else' clause is unnecessary? In simple cases like this one, it can be easy to show that it doesn't matter. Is this a case where we can make things less clear by being more explicit? Consider the example that uses the 'else' block; if another programmer were to come along and wanted to add more code, how easy would it be for them to decide whether to put the new line in the 'else' block or after it?
Could that question indicate that the 'else' statement is part of a code smell? I'm not sure what the smell would be called, I'm not entirely convinced that it is even a smell. What keeps bugging (ha!) me is how similiar it is, at least as a symptom, to why one of our code standards is to require braces everywhere even if they are optional. I might look this up in Scott Meyer's C++ books.

NON-STANDARD:

if ( chaporones_are_gone) drink;
cleanup;

STANDARD:

if ( chaporones_are_gone)
{
drink;
}
cleanup;

The braces are the safety-net to keep the programmer from inadvertantly making changes to code that isn't affected by the 'if'. The compiler will never be a replacement for a thinking human and since humans are fallible, it makes sense to develop habits that keep us from burning ourselves. How can we define a rule to keep us from overusing the 'else' clause? My initial attempt was something like "only use an else if the else block contains another if" but that doesn't really do it. Maybe when the condition includes something like 'Do x unless a=1' but

Let's add an alternative activity, dancing. If you converted the condition into English syntax, you could say "The teenagers will dance or drink depending on whether the chaperones are gone; in any event they'll have to clean up." This says we clean up always and isn't really affected by the condition. There are two exclusive activities mentioned. We never do both. What I notice is that the sentence has two verbs and one object. I'm having flashbacks to sentence diagramming from junior high, not pleasant.

This is related to the discussion about using negative logic in conditions. Yes, the order of the 'then' and 'else' blocks won't matter to the compiler but one way makes it easier for humans to read. Eliezer Yudkowsky discusses this in a Bayesian logic article using the example of why story problems can be so hard for students to understand.

In all the efforts to get programmers to use more powerful tools, maybe we can spare some time to hone our logic skills. However much we'd like expect our tools to do more work for us, there are some things that will always be left to the individual. Computers won't gather requirements for you. Humans can parse the customers requests and know what to take literally or when to use context to help with the interpretation. A sound foundation in the English language can be a powerful tool in the developers toolkit.

Technology is a Harsh Mistress

Technology is a harsh mistress; a modern-day Athena bestowing miraculous improvements and silver bullets with one hand while sowing complexity and chaos with the other. The line of the hopeful souls waiting to receive their next gift stretches back out of sight. You notice the nasty wounds poorly bandaged and the disconcerting gait. When you ask about their plight the barely-coherent reply is, "It's not as bad as it looks. It isn't as bad as the time before last. Next time it will work, I just know it!" and then they shuffle forward as if you weren't there.

The first time I heard the rant on technology not being a silver bullet was over C++ and Object Oriented Programming. While that just shows my age, has anything really changed? These days, XML is all the rage. While XML/XSLT and so forth are not silver bullets, they do provide a common language for describing data. What they do not address is the disparate ways in which data is used. It does not help companies agree on a data model to use to trade data back and forth between themselves. It does not help communicate existing standards to those poor souls tasked with converting a legacy system's data feed being sent to a more modern system. It does not help when other protocols are thrown into the mix, like messaging or business services, at a dizzying pace.

Don't get me wrong, XML, XSD, XSLT, etc., they all have their place. I'm not suggesting we discard our new toys. The question we have to ask ourselves is 'What problem do they solve?' Usually, it's that we hope to be released from the tyranny of change. We can add fields to our hearts content, as long as they are marked as optional and we updated the schema. We can leave out fields -- again, optional ones. We can change tag names, as long as it's ok with the schema. Oh, and did I mention that your partners in communication need to know about all of this? You did remember to update the version number in the XSD, right? Anyone noticed a pattern here? We've traded parsing fixed-length records in a flat file for parsing document object models in never-ending data streams.

What is that weight you still feel on your shoulders? It's the weight of responsibility for your data. We've had the responsibility of managing change thrust upon ourselves. Without understanding your data, communicating with others is an exercise in futility, like a truck with its wheels stuck in the mud on a rain-soaked road in the middle of nowhere. Both sides have to understand and agree on both the data model and the terminology regardless of the tools used to describe them. That's all XML and the rest of the alphabet-soup are, tools. Gifts from the Technology fairy.

So, while you're gazing at your latest gift from Technology, ponder whether you received a silver bullet or a seed of chaos. The first can make life seem like a fondly recalled warm summer day with no worries or rush, the second can make life seem like being dropped into a steaming cauldron of blistering misery. It matters not to her, she'll never run short of supplicants hoping for a silver bullet.