Loosely Coupled

Yesterday two people at the place I'm working gave notice that they'll be leaving the company. There has been a lot of turnover in the six months I've been here. Based on what I've seen, I'm not really surprised. Still, there always seems to be some head scratching by management and some longer tenured employees on why these people are leaving. Here's some of what I've seen. I've already mentioned the poor tooling and processes in place here - starting with Lotus Notes - so I won't rehash that here other than to mention the tooling shortfall has been brought to management's attention many times with no real action. Some people I sit near are in a constant state of emergency. Their production systems break daily (even nights and weekends) because the company's trading partners send messages that don't conform to their messaging API. Instead of rejecting these transactions, management's approach is to ignore the problem, askin...

I've been a fan of Joel on Software for some time. Recently Joel (Spolsky) started a new enterprise, stackoverflow.com , with Jeff Atwood. They've been releasing some entertaining and informative podcasts as part of this new endeavor. Good Stuff. Who knew you could wash your electronics?? ***** Joel has written a few books. One I haven't read yet is titled Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent . While I'm sure this book is helpful, what I really need is a book that can help locate progressive companies which allow employees to work smartly and get things done. I don't know if it's endemic to the region I live or it's more widespread than I imagine, but none of the companies I encounter here are doing anything close to Agile development, few are working with Ruby, most are afraid of open source, none have heard of REST web services, and most are reactive problem solvers rather than proactive....

It's been almost a month since I last posted! I think it's partially due to the fact that I haven't had much interesting work to talk about. Mostly I've been frustrated in trying to convince my teammates why automated unit testing is important (and how to better use our horrible source control system). Most of the objections are the familiar "we'll be writing more test code than application code", "how can we test what we haven't written yet", "it takes too long", etc. I think I've finally convinced them of the benefits though, and we're starting to write automated tests! I'm hoping I can now introduce Test Driven Development and convince them to start writing their tests before the code. I came across a podcast last week from Net Objectives that does a much better job of explaining the benefits of Test Driven Development than I ever could. I thought it was great and I hope it's useful to others as well.

I've noticed a trend in my current organization which I'm sure is common to many companies. I'm having a hard time defining it, but let's call it "Silver Bullet Syndrome"... where when faced with some business problem, companies immediately look for an off the self (OTS) technology solution - many times without understanding the full scope of the problem. The OTS solution is viewed as a "Silver Bullet" and will immediately solve all of the organization's woes. Now I'm not saying all off the shelf software is bad, but often times these business problems are not generic enough to be addressed by a general solution. The lack of flexibility of many OTS solutions compounds the problem, forcing companies to modify business processes or requirements to meet the capabilities of the tool instead of the other way around. Once the tool is in place however, another problem manifests itself. This often starts with a management mandate like, "OK n...

I'm wondering if my company is ready for SOA . Right now the various business units in the company support many pieces of custom built technology which provide essentially the same functionality. Consolidating this functionality into a common, shared set of services is what SOA is all about right? Not only will the footprint of what we need to support be smaller, but we'll be able to meet future business needs faster (getting a jump start by reusing these prebuilt, prepackaged, pretested functionality). Isn't SOA a no brainer in this instance? I'm not so sure. Building successful SOA components (even ones designed for internal use) need a product development approach. Code before SOA is essentially "set it and forget it". Failures in a particular component have a relatively small impact. In a SOA solution, things like scalability, stability, support, and release management are much more important. The significance of these traits increase proportionat...

Change Control & Release Management are two of the most fundamental elements in software engineering. You write code. You release code to the world. All the while, track changes to the code in case something goes horribly wrong and you need to revert to a previous version. It's pretty simple. Modern change control systems like CVS provide additional functionality. When checking in changes, you can include comments to describe the changes. Tagging the repository ties various versions of source files together (i.e. for a release). Branching involves splitting the repository so parallel development can take place (i.e. to support bug fixes to a release while the next version of development continues on the trunk). Changes on the branch can be merged into the trunk, eliminating the need to apply fixes twice. These features are fairly standard in most of the change systems software development teams use today. The point of this post is to ask why some organizations are rel...

Now that we can test jcdTargets from a jcdUnitTester , the final step is to use a combination of JUnit and HTTPUnit to execute and verify the tests. Basically we turn jcdUnitTester into a simple RESTful Web Service where we post the tests. The first set of changes are to jcdUnitTester . My first pass at jcdUnitTester hard coded the test into the JCD. Since we'd like to change the message per test, it'd be better to pass this in as parameter on the HTTP Request. Use the getRequest().getParameterInfo().getWebParameterList() method of JCAPS' HttpServer class to get these values. Other values we'll need, in addition to the test itself, is the queue/topic name where the test will be placed and the queue/topic where jcdUnitTester will listen for the response. Use the same technique described in the previous post to set the replyTo field in the JMS message. This should be the minimum set of values we'll want to send to jcdUnitTester . Some other optional t...