The Software Devotional

Dice's 2010-11 Tech Salary Survey Results

Dice released their 2010-2011 Tech Salary Survey Results. If you have a technical job, take a look and see how you rank.

As you read through it, don't get too bummed by all the average results shown. The numbers generally show a single axis of data, meaning that all the other values are simply average values. An example: In the "Average Salary By Experience" section, the average salary during the 2010-2011 reporting period was $95,399. That's kinda wacky in my experience for someone with more than 15 years of experience. But you have to remember something when you see that number - it is the average across all of the other axes: company size, employment type, region of the country, job title, industry, skill set, education level, etc.

The real numbers for you would be an average of all the respondents' salaries that match your number of years of experience, company size, employment type, region of the country, etc. You get the picture. Due to the simple laws of supply and demand, some areas of the country pay disproportionately more for J2EE developers or good DBAs.

Still, the number are useful. The year-over-year values show where your job is headed in terms of salary across all the axes shown. Compare your current job title or skills to a different title or set of experience to find out if the job change you were mulling over makes sense financially.

All that said, the biggest impact on your salary is likely to be YOU. Are you Smart and Gets Things Done? Do you observe and promote the Practices of an Agile Developer? Do you do what you can to keep your development skills current? Does your boss (and his boss) value what you do? Are you a valuable member of your team (would your team members agree)? Are you seen as a leader by your peers? Not a supervisory leader (that's different), but the guy that people go to when they can't figure something out, or when they need a suggestion for solving a problem. My point here is that unless you work for a company where there just isn't room for higher salaries or career advancement, your salary will be governed mostly by what you do - by making yourself invaluable to the company.

*VERY* Simple Example of Loose Coupling

I have preached here once or twice before about the virtues of loose coupling. I will not belabor the point much more here, except to say that I get lots of emails from people asking about specific examples of loose coupling in their corporate projects. It seems everyone is feeling the same pains. I have also received a fair number of emails that go like this: "I am working on a project and was wondering if you could help me understand loose coupling by showing me how to make my code more loosely coupled." Attached to those messages is a zip file containing their Visual Studio project. I apologize if you are the sender of an email that went unanswered or worse, I answered your email and said that I couldn't spend enough time to give you a good answer. The truth is, it is somewhat difficult to look at a large body of unfamiliar code and quickly offer meaningful guidance. I have said before that a good rule of thumb is that vigilant use of good coding practices makes code easier to test - loose coupling is a paramount example of this principle.

Recently, I have come across code that is more tightly coupled than necessary, making unit testing more difficult than need be.  Here is one very simple example - consider the code below.

Figure 1: Tight Coupling of Method to Complex Parameter Type

Private Sub DoSomeLogging( _
 ByVal p_ApplicationState As ApplicationState)

 With p_ApplicationState

 '...

 End With

End Sub

Nothing looks amiss initially, but try to write a unit test for this method. Do you see it? The DoSomeLogging method is tightly bound to the ApplicationState object. The method isn't useful at all without an ApplicationState object. Also, as you can see, to test this method you must manually construct an ApplicationState object to pass into the DoSomeLogging method. The problem with passing big classes and structures into a method like this is that it can be very time consuming (and potentially dangerous in your production environment) to manually construct such objects.

The boss says write the unit test and ship it, so you do. You build bunches of private methods to manually construct an ApplicationState object. You see that your unit tests pass and everyone's happy. You get to keep your job.

Two weeks later, you make a small change to your code, and start running your unit tests. Many of them are failing. What happened? Someone changed the ApplicationState class and/or the classes that consume it, and now your manual construction of the ApplicationState object is stale. You research the changes that were made, make changes to your ApplicationState construction code, and then deploy your changes. You see that your unit tests pass and everyone's happy.

Two weeks later (yes, it happens again), you make a small change to your code, and start running your unit tests. Many of them are failing. What happened? Someone changed the ApplicationState class and/or the classes that consume it, and now your manual construction of the ApplicationState object is stale. You research the changes that were made, make changes to your ApplicationState construction code, and then deploy your changes. You see that your unit tests pass and everyone's happy.

Two weeks later ... you get the point. The simple feedback I have for this method is that (since the ApplicationState object is difficult to construct and fragile to build manually) it is very likely easier to just pass into DoSomeLogging the data it needs rather than passing in the entire ApplicationState object.  It will absolutely lead to longer parameter lists for your methods and some refactoring will be required, but it is worth the effort. Your testing will go more smoothly and your method will be more useful.

The new and improved DoSomeLogging method will look like the code in Figure 1.

Figure 2: Loosely Coupled Version of Method

Private Sub DoSomeLogging( _
 ByVal p_Parm1 As String, _
 ByVal p_Parm2 As String, _
 ByVal p_Parm3 As String, _
 ByVal p_Parm4 As String)

 '...

End Sub

Not only is this method easier to test, but it is easier to write, it is more likely to be shorter, it is more likely to have a lower cyclomatic complexity, and it is more likely to be reused.

If you read either of my previous articles, you will know that there is more to consider than just loose versus tight coupling. Consider the following.

• What if this method is an overload of another DoSomeLogging method (like the one shown in Figure 2) and its only purpose in life is to make it simple to call the DoSomeLogging method without having to specify all the parameters in every location where the DoSomeLogging method is called. Good call, I think passing ApplicationState as a parameter is a good move.
• What if this method was intended to be used only with ApplicationState objects. My gut tells me that perhaps the DoSomeLogging should have been a method on the ApplicationState class. Even if it isn't, it is still worth considering the pros/cons of decoupling the DoSomeLogging method from the ApplicationState object. You will need to consider how often DoSomeLogging is called (see bullet above), how fool-proof you want to make the DoSomeLogging (you might want to prevent someone from passing in the wrong parameters), and lots of other things before knowing which way is the right way to go: loose versus tight coupling.
• Keep it simple. One look at the code in Figure 1 tells you what the method does and its likely consumers. Readability is a paramount goal of mine and only egregious problems are likely to trump readability.
  

If you use the difficulty-of-unit-testing method of judging code smell, you would have caught this one right off. Luckily, I think this type of coupling is relatively easy to fix and even easier to avoid.

Zen and the Art of Loose Coupling

The volume of responses to my previous article about loose coupling was crazy. It wasn't just the volume - the responses were all over the place. Some of the themes of the comments really surprised me. Some readers vehemently agreed with me, other suggested that loose coupling isn't as big a deal as I made it out to be, and others suggested that there were other areas where I should have focused my attention.

By far, the heaviest volume of responses came from readers pointing out that too much loose coupling is a really bad thing as well. I don't disagree with this point - I even made this point in my post. However, as I replied to some of the authors, I WOULD LOVE TO BE STRUGGLING WITH TOO MUCH LOOSE COUPLING instead of being crippled by too little loose coupling. Making code more tightly coupled is ALWAYS, ALWAYS, ALWAYS easier than modifying tightly coupled code to be more loosely coupled. Besides, I just don't see nearly the incidence of overly loosely coupled code - it just isn't out there to the same degree as tightly coupled code. Not only that, but it just isn't as painful an experience to deal with.

It's an odd thing - my previous post about unit testing has been a big source of short term contract jobs for me. In this capacity, I have been called upon to help with all sorts of unit testing projects from helping to get unit testing kicked off for a project, help write unit tests, and just helping out with understanding how best to use unit tests to increase software quality. Many of the projects I see are nearly untestable, unstable, and difficult to change because of the high likelihood of breaking the project. I see people that are afraid to make changes to this sort of code, which makes it difficult to make needed changes to these projects. In the unit testing article mentioned above, I made the point that a homing beacon for poorly written software, especially tightly coupled software, is that it is difficult to unit test. Count on it.

Let me say it again: like everything else, loose coupling is a balancing act. A good architect will find his Zen for loose coupling and can be a good guide. In many cases, knowing how and when to loosely couple your software will be a mostly intuitive process for someone with years of experience. However, casting error on the side of more loose coupling than you might need will give you a more maintainable and easily tested system than by leaning toward more tight coupling.

Before moving on, I have to admit that I haven't given props to the contribution of cohesion in the role of maintainable software. I'm not going to try to explain it better or more concisely than the cohesion wiki: "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are." I have more to say about the role of cohesion in quality, but I will save that for another post.

Ideally, we will find a balance between the two extremes (loose coupling and tight coupling), but I'll take software that is too loosely coupled over software that is too tightly coupled - every time.

Resources:

• If you want a more elaborate analysis of cohesion, study the sample chapter from the book The Practical Guide to Structured Systems Design. The chapter does a good job illustrating the differences between the various forms of cohesion.
• Also, the book mentioned above, The Practical Guide to Structured Systems Design, is a great resource for architects looking to understand how to build maintainable software. It leans heavily toward an academic view of software (that's not all bad), and is very long-winded in parts.
• WWMFD? Martin Fowler is always a good source for software-related thoughts. He published an article way back in a 2001 issue of IEEE Software titled "Reducing Coupling". When in doubt, ask yourself What Would Martin Fowler Do?
• By "maintainable software" (I used this nebulous term above), I mean software that is relatively easy to understand, troubleshoot, modify, extend, and test. I include this definition here to direct you to a post by Jeremy Miller where he points out several qualities that make software difficult to work with. His post is well worth your time to read.

devLink 2009

Tennessee developers: registration opened on April 1 for devLink 2009. devLink is a software development conference held in Nashville every year - this year it is scheduled for Thursday, August 13 through Saturday, August 15 and will be held  at the David Lipscomb University campus. Like the big national conferences, devLink provides great session content by great speakers. But unlike the big national conferences, devLink limits attendance (this year to 800 attendees) and its non-procrastinator price is only $75 (goes up to $100 after April 15). Register now because it sells out every year.

devlink is organized by John Kellar: speaker, developer, blogger, and nice guy.

devLink is one of a growing number of "local" conferences being organized all over the country. In general, they are on similar footing as VSLive, DevConnections, and the SD conferences in terms of content, but lack the big-budget venue and marketing blitz. This appeals greatly to me because I dislike the travel expenses of getting to the conferences and because many of the national conferences slant session content toward the material being pushed by the big marketing departments of Microsoft, Oracle and the like. The "local" conferences that come to mind (without Googling) are devLink (Nashville, TN), CodeStock (Knoxville, TN), and CodeMash (Sandusky, OH). Check them out and attend the one that's most convenient to you.

If you know of any that I've missed, please let me know by posting here or emailing me.

SimpleDB Explorer on Bits du Jour This Sunday

Do you remember the days of having to create tables, add columns to tables, and query the database using text-based SQL tools to do it? My college professor made us do it that way so we would learn SQL. When I used the database management tools for the first time, I was disappointed to find that they weren't a lot easier to use (maybe because I had gotten so good at using SQL, but that's another discussion). Dang that sucked. Thankfully, things have gotten a lot easier since then.

I got to taste my disdain for the lack of tools for new products in the early days of programming using Amazon's SimpleDB. It was right back to the days of old - no good tools. I came across SimpleDB Explorer a couple of months ago and I love it. SimpleDB Explorer is essentially SQL Server Management Studio for SimpleDB databases (better in some ways). If you use SimpleDB, you should give it a try.

So, the reason for this post: I just noticed that SimpleDB Explorer will be on Bits du Jour on Sunday, March 1. Bits du Jour helps software vendors market themselves by pushing great software at insane prices. The normal price of SimpleDB Explorer is $34.95 and Bits du Jour will be selling it for $19.95 this Sunday only.

If you don't know much about SimpleDB Explorer, try out their 30 day free trial this weekend. Then buy it on Sunday.

Check out some screen shots of the product on the SimpleDB Explorer web site.

Post back here if you liked it.

Loose Coupling is Good - Tight Coupling is the Devil

I have been struggling for some time to explain to fellow developers the merits of loose coupling. It's usually a hard argument to make. To argue for loose coupling, it is necessary to overcome the arguments against it: high degrees of loose coupling in otherwise small projects (small number of classes, small number of developers, little dependence on third-party tools, few database tables, very short development cycle, etc.) is almost never going to give much bang for the buck. However, as software projects mature, an architectural tenacity toward loose coupling in the early stages of a project can mean big (BIG) payoffs later.

Why don't more developers embrace loose coupling? To be sure, it's harder than tightly coupling your code. From the average developer's perspective, tighter coupling means that features are coded faster, bugs are squashed more quickly, direct relationships between objects are easier to conceptualize for architects and easier to visualize for developers, IntelliSense for .NET developers works better, and problems are tracked down more quickly. Try arguing against all that! The truth is, direct relationships between systems and components simplifies life on smallish projects. However, as a project grows, tight coupling will likely cause some of the most painful growing pains you will face as a software developer.

What is Loose Coupling?

If you're still scratching your head because you don't quite understand what loose coupling is, there are lots of reasonably good definitions on the web (this is a pretty good one and this one is even better if you don't mind the academic slant). In short, loose coupling is a design goal that seeks to reduce the interdependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component. Hold on, isn't this is same tired idea my 1st year computer science professor called encapsulation? Got it, thanks. Not exactly - encapsulation in an OOP sense generally aims to guide (or force) users of your components to use your classes correctly and makes it harder to abuse the class's functionality by hiding the implementation. Loose coupling is a much more generic concept intended to increase the flexibility of a system, make it more maintainable, and make the entire framework more 'stable'.

How do you measure coupling? Not easily, I'm afraid. The degree of coupling between two components can be qualitatively measured by determining the effects of changing the contract or interface between two components or systems. For example:

• What would happen if you added or deleted a property from a class?
• What would happen if you changed the data type of a column in a table?
• What would happen if you added a column to a table?
• What would happen if you changed you asynchronous email component?
• What would happen if your database server changed from SQL Server to mySQL or Oracle?

The degree of pain that each of these changes would cause you is a good qualitative measurement of how tightly coupled your components are to the components they depend on.

Symptoms of Tightly Coupled Systems

If you have ever deployed a seemingly innocuous change only to find that other parts of your system broke when you did, then you have likely experienced one of the chief symptoms, in my experience, of tight coupling. If you have ever experienced a problem where it was hard to fix a problem because of the number of changes to other components that were required to make the change safely, then you have experienced the symptoms of tight coupling. If you find yourself repeatedly choosing "the poor man's solution" because the real solution was just too risky or required too many components to change, then you were likely the victim of tight coupling.

For the reasons I gave previously, tight coupling generally speeds the development of smallish projects. The pains caused by tight coupling aren't generally felt until the project starts to grow. As features (and developers) are added to a project, the original design purity grows cloudy in imperceptible increments. The pure evil of tight coupling becomes most apparent once the product has grown in the number of features that have been bolted on and has expanded past the first few developers that set the vision for the project's architecture.

The problem is, it is only when you have reached the stage in a project when you are feeling the pains of tight coupling that it is reaching the stage where it becomes very difficult to remedy. This is why tight coupling is such an insidious problem - even experienced and otherwise conscientious developers will be lulled by the comforts of tight coupling. It feels good. Control just feels nice.

Because your earlier design and coding choices have led to a system that is difficult to maintain without considerable grief, tight coupling is a notorious form of technical debt. In fact, in my experience, a considerable portion of redesign-from-the-ground-up projects are initiated because of high degrees of tight coupling making incremental improvement seemingly impossible or impractical (but resist this temptation at all costs).

Loose Coupling In Your Projects

Let's make sure we are on the same page. You can never completely loosely couple everything - that's a given. At some point, some part of your software will be VERY tightly coupled to something else. The point isn't to loosely couple everything. The primary goal is to reduce the amount of work and the risk involved when you change the interfaces between components of your system. Using this as our goal, we should look for areas where changes will cause lots of downstream work. You also need to consider the likelihood that changes to a particular system will occur. Face it, most people aren't going to change their database servers often, so maybe that's not your main focus. However, the licensing tool, EDI message parser, logging framework, email product, etc. are all great candidates for loose coupling.

Look a little closer - you will also find that there are interfaces between the components inside your software that should be loosely coupled. In fact, these are likely to be the areas of tight coupling that are the most difficult to fix.

Very simplistically, you should look for ways to maintain a consistent interface that hides changes that occur. If you send email notifications from your software, a loose coupling approach would be to build an interface around your email component of choice exposing only the functionality you need for your application. If done correctly, you could easily change email component providers with few changes to your application. In this simple example, only the implementation of the email interface wrapper would need to change - create an object of a different type, set different properties, and call a different method to send the email. By loosely coupling, we didn't eliminate all the work required to make a change, but we were able to isolate the work to a very manageable, easily testable, low risk, and quickly implemented project.

Keep in mind that loose coupling comes at a price. Consider these issues:

• Consider the cost of implementing loosely coupled interfaces versus a more tightly coupled solution. For sure, loosely coupled interfaces mean not only more code but also more complex code.
• Tightly coupled interfaces are easier to conceptualize for architects, easier to code for developers, and easier to troubleshoot when problems are suspected.
• The cost of tightly coupled interfaces will be measured in frustration, not necessarily in the developer time it will take to fix the tight coupling. However, ghastly amounts of developer time and increased project risk are two of the usual suspects. With tight coupling, you will find that seemingly simple changes turn into complex coding projects and become very difficult to test.
• The cost of uncoupling tightly coupled interfaces down the road can be very costly and will likely be very risky.
• How likely is it that a tightly coupled interface will need to change in future versions of your code.

As you get a good feel for loose coupling, you will actually learn to take advantage of the looseness of the application. The looseness that you will exploit will be the same parts that traditionally make loose coupling more difficult. Consider being able to make components of your system pluggable - you could replace pieces interchangeably. Consider how testing a large application could be made more simple if you replaced a complex business object or data layer object with a simple mock that would enable test cases to exercise other components of the system.

Evolution of the Software Developer

In a great blog post from last year, Jeremy Miller chronicles the maturation process of a software developer from the perspective of loose coupling. Most experienced developers have intuitively known about this progression even if they couldn't put it into words. To paraphrase, Jeremy explains that developers start with the "Just Make It Work" philosophy, fixing problems wherever they realize there might be a problem. Quickly, the developers who wriggle out of the primordial coding goo and begin to realize that there are 'correct' places for things, and strive to put things in their 'correct' place. Still more time passes and these same developers begin to realize that loose coupling is important in all but very simple projects. For those developers who live long enough, their loose coupling fu evolves naturally into the use of inversion of control.

To help get you further along the path, work through thought experiments to consider how you will change systems later and how you will need to go about making the required changes. As you do, weigh the costs and benefits of loose coupling.

With any luck, in future posts I will work through some concrete examples of places where you should consider loose coupling and how to implement it.