Loosely Coupled

I was inspired by this talk from RailsConf given by Robert "Uncle Bob" Martin. It's a really entertaining talk and you should check it out if you haven't already. During the talk, the topic of professionalism came up and what it means to be a "professional software developer" (maybe 2/3 of the way through). Professionalism in software development is a topic that's not well defined and certainly has different meanings to different people. Can you be considered a pro, for instance, if you don't provide a set of automated tests for your code? What if you don't use source control? Do you feel the need to always create a custom build file (make, ant, or maven script) so you can build independent of an IDE? Do your "professional" standards change depending on if you're creating "prototypes" rather than designing code for production? I know which things I strive to do on every project I work on. But the standards for the t...

I guess I still get a little surprised when I see code for a Java project and there's not an automated Maven build. These projects often have an Ant script (many times the default one generated by Netbeans or Eclipse), but seldom a Maven POM file. I wonder why? Especially since Maven is so easy to use and really adds value over a vanilla Ant build. Maven takes an Ant build to a higher level of abstraction to where it's easier to manage and change. What I think I like most, is the idea of the Maven repository. It's a nice way to store and share application dependencies. In a typical Ant project, dependent JARs will be stored in source control along side the source code (typically in a lib directory). This can make initial checkouts of these projects S-L-O-W. Compounding the problem is when a set of projects use a framework like Spring. Each project will store it's own set of Spring jars with the source, forcing developers to download the same set of jars mult...

Recently I retrofitted some code I was working on to utilize Spring . It's been some time since I'd used it and I'd forgotten how much I enjoy coding in this framework. It really helps me write better, cleaner code. As developers, we always strive to create plug-and-play architectures - you know, code to an interface, achieve easily swappable implementations, etc. That in itself really isn't that hard to do, but Spring really shines in enforcing this idea. My original code (for Jena) needed to grab some Resource references from the model and looked something like this... {method declaration} OntologyModel model = {get model reference} URI resourceUri = new URI("http://www.myCompany.com/MC#myResource1"); Reoruce myResource = model.getResource(resourceUri); {additional business logic} The equivalent Spring configuration replacement for this code looks like this... <bean id="myResource" class="com.myCompany.Resource" factory-bean="...

Since outlining a brief list of online technical resources for my rookie coder, I thought it'd be a good idea to also supply a brief reading list of technical books that could have a place on any programmers shelf. For this list, I wanted to focus on books that provide transferable skills - suggestions of different techniques and ways of thinking than someone might otherwise be exposed to. This knowledge can be able leveraged regardless of specific technologies or platforms. Here's the list: Core J2EE Patterns – I have an earlier version of this book and it’s a solid J2EE reference. The real benefit in this book is the set of J2EE architectural patterns (which builds on the Gang of Four [GoF] core patterns) and would also apply to server side development in .Net. Some of the info on JSP or EJB may be a little dated with recent additions to the Java language, but still a great reference. Patterns of Enterprise Application Architecture is another great book with a similar...

As I stated in my last mentoring post , one thing new professionals need to learn is how to stay technically current and continue to grow their skills in the absence of formal training. Here's a list of some online technical resources and tools I think any new professional would find helpful. Martin Fowler's Bliki . Martin Fowler always has interesting things to say about object oriented design, agile development, and software development in general. He is a thought leader and always says smart things. InfoQ This site has a ton of info about a ton of software development topics. What I like most about this site is that there are a lot of videos. I learn better this way. It’s nice to watch someone explain a topic and see the examples. Here’s a Martin Fowler presentation on InfoQ about SOA and ESB. StackOverflow . This is basically a Q&A site for software developers. It’s fairly new and high quality. If you really get stumped on how to do something or want ...

When is the right time to adopt some new technology - the shiny "silver bullet" solution that's going to meet all your current and future business needs, make your team ultra responsive to your users, and totally allow you to kick butt? Before screaming "get it now! get it now!", consider the following. This technology is new, cutting edge stuff. Not many people are doing it. Where can you find help and support when you inevitably hit some road blocks? Will you be forced to troll message boards and user groups for solutions? Will you be using the technology in a way that hasn't really been anticipated, pushing you out even further from the mainstream and making it even harder to get good support? Is this a technology you're buying? If so, how's the company's technical support and reputation? What success stories can they point to? Can you "make do" with some existing (better supported, more widely implemented) solution until thi...

Recently, I was asked to act as a mentor for a junior level developer. It was a little awkward in as much as I hardly know this person - we've only briefly met, we're not working on the same team, and not even for the same company. I'm not even sure what to topics to mentor on. Remembering back, one of the hardest things for me when I transitioned from a college setting to professional was learning how to stay current and continue to push my skill set forward. Until graduation, you're continuously being fed information and guided on what to learn. After, you need to learn to forage for yourself. Learning how to do this and where to look is where I thought we might begin. Like any new relationship, I thought the best place to start was with a brief introduction, then see where I might be able to best help this new professional. Here's an excerpt of my introductory email: (Introductory text..) Just to give you some insight into my background, I've been profe...

This topic seems to be pretty popular lately. First I saw Martin Fowler's comment on technical debt last week. Then Jeff Atwood brought up the topic in this week's StackOverflow podcast (@53:30). Basically, technical debt is the price you pay down the road for a "less than optimal" design choice today. I particularly liked Atwood's metaphor that you know you've incurred technical debt when you give a long sigh every time you need to modify some part of the code base. You know that the changes are going to be painful (and expensive) to make. It's time to refactor. A few comments based on my experience. I've been noticing less technical debt in my own code since starting to follow a test driven development approach more religiously. Maybe there's something about this approach which makes your code more "real than theoretical" from the start. It helps you make better decisions without thinking about it too much. Maybe it's becaus...

I would really like to post more often, but frankly, I've been too busy. The New Year brought a change of job scenery and I've been really busy getting up to speed and learning a ton of new things. That's not to say I haven't been writing at all. As I come up to speed here, I'm taking the opportunity to capture what I learn in a development wiki. My new team has a wiki instance in place, but it's been lightly used to this point. I'm a huge fan of using wikis for development . I like to leverage the wiki as a focal point to capture technical ideas and documentation for the team. Most people seem eager to contribute, so I hope it takes off. One point here, we're using the wiki included with SharePoint . It's not nearly as hard to edit as MediaWiki (the Wikipedia wiki engine), but I still prefer MoinMoin (used by many Apache projects). The heart of the software being built here relies on Ontology , and leveraging the data stored in that ontolog...

As the work calendar turns to 2009, it's natural to reflect on the past year. Professionally, 2008 was a very frustrating year. Part of it had to do with the tools I was using, part of it had to do with the project I was working on, and a lot of my frustration was that I felt like I wasn't being heard. Instead of rehashing some of the difficulties I've experienced over the past year, I invite you to read some of my previous posts . So, how do I hope to course correct in 2009? Do More Many times in 2008, I found myself waiting for others to complete some part of their work so I could do mine. Other times, we hit limitations of the development platform we were working on and waited for management approval for how we should proceed. In these instances I often had an alternative in mind for how to proceed, but didn't. I instead hung back and tried to let others do their jobs, make their own decisions, and get consensus on an approach. I regret this approach. I wish I h...

Software development is complex. A lot of communication is needed to coordinate with users and between teams to synchronize efforts. On large teams developing distributed systems, effective communication is exponentially harder. In addition to the users and development teams, you also need to deal with system admins, DBAs, network, and change control specialists. In many environments, this later group of people (the system admins, DBAs, etc.) do not get involved with the project until late stages. The development team might have free reign over development databases for instance, but when the code migrates to a certification environment things are suddenly very different. Teams move from surroundings where they have total control of machine settings, databases, and resources to an environment where they have none. Often, during the migration to a test or production environment things are often "forgotten". Things that often don't make it into an application's ch...

Good things always have that "secret sauce" - the element that sets it apart from the pack and makes it better than anything else. The "secret sauce" takes something ordinary and makes it extraordinary. It's a Mac vs. a laptop. Disney World vs. a theme park. A Big Mac vs. a hamburger. When I hear company execs talk about what sets their companies apart, it seems there's no real "secret" to the sauce after all. It boils down to hard work and a commitment to your customers. A commitment to a better user experience. A commitment to treating every guest interaction "special". A commitment to a good hamburger every time. There's not a magic switch you can flip... it's a commitment to excellence through hard work. Looking for a shortcut to this kind of success is a waste of time. All too often I've seen software development teams look for magic switches rather than commit to the hard work of fixing the underlying problem. ...

Contractors - programming contractors, general home contractors like builders, plumbers or electricians, and even mechanics - have bad reputations. While everyone needs these skilled professionals to complete work where they have little expertise, there an inherent distrust in these relationships. Distrust - where total trust is needed. Many times it's unwarranted because contractors are as honest and hard working as anyone else. So why is it so? I think a number or relatively minor, easily correctable behaviors lead to this perception. Personally, I have changed mechanics more than I care to comment on. Not because I felt they were screwing me necessarily, but mostly because they didn't explain the work they were performing to my satisfaction. This led me to doubt their abilities. The doubt and distrust lead me to look for another mechanic who I have more confidence in. It's too bad. I hate shopping around for new mechanics. At home, we recently added a room to ou...

I'm the type of person who constantly looks for ways to improve. No matter how well things go, I'm always striving to "plus" an experience - smooth out the rougher edges to make the next time even better. Sometimes the need to do this drives me a little nuts. It drives my wife really nuts! When things don't go well, this task can be a little overwhelming (and depressing). There are so many areas for improvement, it's hard to know where to begin. I've spent the last year or so, reexamining my software development experience - looking for trends in the tools and ideas that helped the teams I was on to be highly productive (and conversely where the lack of some practices led to a lack of productivity and frustration). Combined with many of the things I've read by Spolsky , Fowler , and the Poppendiecks . I've created a list of criteria I'd consider essential in an ideal software development environment. Talk to the target user...

I haven't been doing too much development as I wait (and wait and wait) for our acceptance testing to complete. Here's a quick rundown of what I've been thinking about while waiting for that to complete.... I've been reading and participating in some of the discussions on StackOverflow . It's a great way to get a pulse on what others are thinking about and working on. I've also been able to pick up some things I never knew existed before. I've taken part in other question and answer type sites before and I had my doubts how helpful this would really be... I've been pleasantly surprised. I listened to these great podcasts on alternative energy. Grass as fuel?? Pretty cool. I've been thinking about maybe getting some solar panels for my house. I would never have thought that the Northeast would be a good place for these until I saw a cool episode of Nova sometime back where someone in Mass. had some installed on their house. Now maybe I...

I'm usually not in charge of scheduling. I've contributed to schedules, but someone else - usually someone from management - drives schedule creation. I also can't remember a situation where the schedule actually worked. What I mean by this is, a lot of time was spent to create schedules for 2-3 months into the future - then not really revisited (adjusted) for a month or more. By this time something invariably happens (priorities change, initial tasks take longer than expected, vacations/time off weren't accounted for, etc.). This throws the entire thing out of whack and quickly makes it obsolete. A month or more will pass, then the whole process starts again with the creation of another schedule. For the project I'm currently on we've spent a lot of time creating 2 schedules from scratch and are currently creating a third. The first two have been complete failures and I have low expectations for the third. It's frustrating to spend a lot of time and ...

Steve Yegge has this great post today about business requirements and building software that you'd personally use in a domain that you actually know . Great stuff! I need to figure out a way to print wallet size copies to hand out at requirement meetings.

As the struggles continue with the application rewrite I'm currently involved with, I've read and reread these articles by Joel Spolsky , James Shore , and Chad Fowler on why this path generally leads to failure. After I finish reading articles like these I often ask myself: since many of the industry thought leaders think these projects are a bad idea, why are they still so common? I mean, Joel's article was written in 2000. Eight years later (an eternity in technology) that article is still extremely relevant, but it's lesson has failed to penetrate mainstream thought. There's not enough industry focus on how best to approach legacy system enhancements. Many software development articles that garner the most attention focus on quality improvements delivered through innovations in technology - new programming languages, frameworks, APIs , architectures, and hardware. While that stuff's definitely important, they're relatively little help to applicat...

Almost every place I've worked struggles (in varying degrees) documenting business requirements. Maybe not the initial requirements, but the new requirements/enhancements that emerge as releases are delivered. They usually stem from a conversation that starts out, "I really like this, but it would be really cool if it could also do this other thing I had not thought of until now." This is a bigger than normal issue at the place I'm currently working. Mostly it's because new requirements are not captured in the same documents as the original specification. Instead, a new document is created and placed into a shared folder on the network (or sometimes a series of different folders). Over time, there are a lot of distributed requirement documents and it's really difficult to figure out what the system is supposed to do (and where to look for this information). Please, place all your application requirements in a single coherent "document"! Make ...

In another discussion recently about SOA , it still surprises me a little that people, technical people, don't get that there's not much new here. For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code. Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call. If you're already supporting message-oriented applications using MQ or JMS , these messages are now HTTP requests. The process of decomposing the application into reusable services is essentially the same. The real point here is, if you already have a modularized architecture and you're having problems with application crashes, a swi...