Instantly Become a Better Developer

If you are not interested in becoming a better software developer / engineer, you do not need to read this post. However, if you have an inner desire to improve your skills (with minimal investment), please read on...

Static analysis tools are a great way to becoming a better software developer. These tools have the ability to scan your source code, and give you feedback that can make your applications run faster and less prone to errors.

FindBugs, by Bill Pugh and his team, is a great example of a static analysis tool. After listening to his interview on the Java Posse, I was very interested and excited to give FindBugs a try. After installing it as a plugin for Eclipse, I ran it on a random project that I had in my workspace. It notified me of some areas where the code could be improved, but it also gave a very clear explanation of why it was making the suggestions it made:

So if you are interested in becoming a better software developer, I don't think you can get a better return on your investment than employing FindBugs, or any other static analysis tools.

Classicist or Mockist Test Driven Developer

I just read an interesting article titled "Mocks Aren't Stubs", by Martin Fowler. In this article, he explains the difference between a Classicist and Mockist TDDer (Test Driven Developer). After reading the article, I started to reflect on the TDDer style I have been practicing and if I needed to reevaluate my strategy.

When I first started practicing TDD, I didn't use Mock objects. Instead, I relied heavily on Dummies and Stubs. If I was unit testing object A that collaborated with object B, then I would have a stub implementation of B that had states that could be set. For instance, if I was testing method A.calculatePay(), that called B.getHourlyRate() that returned a Float, then the stub implementation of B would have a method called setHourlyRate() giving me the ability to control what was returned from the B.getHourlyRate() method. This approach did meet my needs, although it really cluttered up my testing package and the stubs soon became very messy. Imagine if B.getHourlyRate() returned a Float but also had the possibility to throw 3 different types of exceptions that should be handled differently in object A. If this was the case, I had a very complicated stub implementation of B in order to control whether to return the Float or throw 1 of the three exceptions. By doing this, I found myself writing more code to control the behavior of the stub implementation rather than testing A.calculatePay().

After I became familiar with mock frameworks, it really simplified my unit tests. Instead of creating a stub implementation of B, and programmatically controlling it's behavior, I leveraged a mock object framework that did most of the work for me. The Tests with Mock Objects portion of Martin Fowler's article shows examples of how this can be accomplished. What I found was an increase in productivity because I was no longer focused on building stub code to handle all of the different cases, but actually working on testing A.calculatePay().

Ultimately, whether you call yourself a Classicist or Mockist TDDer, in my opinion, as long as you are practicing TDD, you are on the right path.

Knowledge Portfolio Investing Suggestions

After 7 years of experience in Software Development, I have learned that it is absolutely critical to your career to continually invest in your knowledge portfolio. When I refer to the Knowledge Portfolio, I am talking about your personal bank account of skills and experience that someone is willing to pay for. It is the selling point to our customers. It is the reason why they will choose us over someone else vying for the contract - and let's be honest, we are all selling our skills to a customer whether we carry the title of consultant or permanent employee. When investing in my portfolio, I have learned that diversity and focus are two important things to consider.

Diversity

When trying to decide what to learn next, take a minute for self assessment. Should you focus your time on a hard skill or is it time to invest in a soft skill. Many of us are eager to learn the latest framework or programming language (both of which probably solves the same problem that the old framework and programming language did), but do we take the time to invest in our softer skills, like how we relate to others? I have just started to read, for the third time, 7 Habits of Highly Successful People. Every time I read this book, I learn more about myself and acquire practices that I can put into place that will increase the quality of my relationships with others. For those of us that do not work in silos, and we either report to someone or have others report to us, maybe we should consider enhancing our interpersonal, communication or some other soft skill.

Focus

Since time is precious, and in short supply, be focused during the time that you have set aside for your portfolio investment. I think that it is completely appropriate to spend the first 5 - 10 minutes of your investment time, planning what it is that you are going to accomplish. Define your goals and how you are going to meet those goals. At the end of your time, critique how you did. Did you meet your goals? How could you have been more productive and what are you going to do next time in order to ensure that you are more productive? This may seem like a tedious exercise, but speaking from experience, I know how much time can be wasted without clearly defined goals of what you are trying to accomplish.

As you know, technology moves pretty fast. If you want to move with it, make sure that you are spending the time necessary investing in your knowledge portfolio.

Apache Geronimo First Look...Impressive

I have a tendency to be curious about everything. Software development and design, is no exception. Lately my curiosity has led me to taking a look at Application Integration Solutions.

Examining the experience that I have with various integration techniques, (Socket Layer Communications, Remote Method Invocation, Web Services) I realized that the one that I was missing was Message Driven Beans (MDB). So I decided the other night to give both MDBs and Geronimo a try.

After installing Geronimo I immediately went to their Wiki to learn more about the deployment architecture. I was very surprised to find source code for an MDB, along with step-by-step instructions on how to build and deploy it. I was excited, but I tempered my excitement by recalling all of the other tutorials that I have gone through in the past, that reportedly worked at one point and time, but not when you were running it locally on your machine. Has anyone had this type of experience?

So I took a deep breath, and decided to walk through the tutorial anyways. Imagine my excitement when everything worked perfectly the first time without any problems. In under 20 minutes, I had a fully functional MDB deployed on Geronimo. Instead of wasting precious time, trying to investigate problems with Geronimo or the given source code, I could now start investing time into learning more about MDBs.

Special kudos to Lasantha Ranaweera, who I am assuming is the developer who wrote this great introductory example of working with MDBs, as well as the Wiki editor that put together such a nice tutorial on how to build and deploy this application on Geronimo. With this level of quality in both source code and documentation, I am planning on using Geronimo for all of my JEE adventures of curiousity.

TDD Koolaid :- Sip don't Chug

I have been getting into a lot of discussion lately regarding Test Driven Development. For those of you that do not know me, I am a TDD practioner (some may call me a fanatic). However, I was not always that way...

My TDD journey began a couple of years ago when someone handed me the book Extreme Programming Installed. I was part of team given the task to evaluate different Methodologies for Software Development. Fate led me to study Extreme Programming, but I will leave that for a different post. In my view, the best way to learn something is to put it into practice. Test Driven Development seemed like as good a candidate as any to start learning Extreme Programming, so I did.

Starting to practice Test Driven Development was not easy. For so long, I had operated in the mode of "Coding Blindly". The cycle of doing J2EE development was lengthy and insane: write code, compile, build distribution, deploy to application server, pray that it works!!! To change that mindset, as ridiculous as it was, was a challenge. Instead, I started to force myself to write tests against the business logic layer of my application. (Only recently have I started writing tests against the Data Access Layer, due to lack of methodologies of doing so). By writing my tests first, no longer was I operating blindly. Through the use of expectations, I had a goal in front of me that I was trying to reach and I was rewarded by the "almighty green bar" when I reached it.

I actually found myself working less. By writing the tests first, and building tests against objects and methods that were not even created yet, I allowed the IDE (Integrated Development Environment) to do all of the heavy lifting for me. With a click of a button, I was able to create classes and methods that allowed my tests to compile. With some creativity, I was able to control behavior of the dependencies, and test many scenarios that were impossible if not difficult to do while I was "Coding Blindly".

I have to admit, TDD was not easy to get used to. It required a lot of time, patience and research. I would like to challenge all of you who are reading this post to start applying some of the test driven practices. If you are having a hard time "chugging the TDD Koolaid" sip it instead. Take small steps and watch how more productive you become, how clean your code looks, how much more secure you will feel in the code that you write, and not to mention how much fun it will become.

Switching Blogs

Well, I have finally decided to create a new blog. I got tired of all of the spam that I was receiving from my previous blog. So much so, that I found myself less eager to create any more posts, in fear that it would lure more spammers. So, instead, I have decided to make blogger.com my new home.

Let me introduce myself. I am an owner of a consulting company / software developer / trainer / open source fan / family / Christian young man. I wear many titles, so you never know what you might find on this post. I may share some good tips and information, or I may reach out and pose some questions. It should be fun.

Looking forward to hearing and talking to you.