The Retrospector

In the corporate world, there is a very heavy weight put on successful delivery. Companies usually understand that some things have learning curves, but where do you draw the line on testing out new technologies before you actually stop and deliver something?

Are you known as the guy that knows about a lot of things but never delivers on time? Can you relate to someone that always delivers on time but ends up using the same outdated approach over and over again? Maybe you’re somewhere in the middle, but how do you know when to balance learning with delivery?

I’ll define some considerations you need to take, factors that should effect your decision, and give some tips on how to apply what’s known to deciding which approach you should take to still be successful.

Things to consider

• Time – How much time do you have? Are your customers patient? Is there a high visibility on whether or not you can deliver quickly?
• Risk – Do you already have success with similar projects? How much experience does your team have in completing like tasks? Do already know how to implement all requirements requested?
• Resources – Do you have enough help to get everything done? Are you in a volatile environment where people aren’t able to dedicate themselves long enough to be effective? Is everyone involved able to focus on just your project without worrying about other commitments?

All of these items should be weighed in when deciding on a project plan. If you know there’s a very low risk in being able to deliver on time, it’s likely a good opportunity to begin trying new things or experimenting with new technologies that can be applied to some of the components.

If the risk is medium or high that you might not meet the expected delivery, using what you know will work should take precedence over experimenting with frameworks or widgets you’re unsure of.

(more…)

In today’s competitive software development world, companies are experimenting with many scenarios to reduce the cost of their software. Some companies prefer to develop everything in-house. Others prefer to outsource everything. With both options being rather expensive as professionals aren’t exactly the most affordable, some companies are considering outsourcing to companies abroad.

Offshore outsourcing has been proven to succeed for some companies, but it isn’t the alternative choice for everyone. One alternative with many similarities is to use college students as a workforce for the same elements you would consider off-shoring. I’m sure there are some companies that have found the off-shoring business model suits them perfectly. I say “good for them” if they got it to work out the way they wanted.

I have to admit that I’ve only been involved with one major project that involved an offshore development team and the entire experience was horrible. I can’t say much for how it works now (a few years later), but I imagine things have probably gotten better. What I am interested in pointing out is an environment I’ve seen work very successfully with many similarities.

(more…)

I stumbled onto an article in Ry Lowry’s blog that included a piece about his frustration with applying test driven development (TDD) to a commercial framework.

To summarize, he’s comparing TDD applied to an open source framework (Spring) with applying it to the commercial product. Spring was certainly designed for TDD and being in the open source community is very easily integrated with near any of the popular testing methods.

The commercial product he’s using doesn’t seem to have any easy way to be tested using many of the testing tools that are out there from a TDD perspective where you start with unit tests and work your way up to the different testing levels until you have near-end-user-like testing as well.

A couple of things come to mind that I think add value to the discussion:

(more…)

Code reuse in software development is something assumed literally through re-using bits of code in more than one place. It is truly achieved through using common libraries and interfaces accessible to both the entire application and to other applications in the domain.

What is code reuse?

Literal definition: Code reuse is the practice of using existing code…again. There are some benefits and drawbacks to code reuse as it is defined here. If you take the literal meaning of the terms you end up with simply using what you’ve got in another place.

Benefits

• Speed – I tell you what, I can copy/paste stuff like no other. My fingers can instinctively assume the copy/paste position on near any keyboard shape w/o me even realizing it.
• Easy – there’s not really much thought involved in having to just duplicate your code in another applicable area of the application, or in another application. If it works in one place, it’s more than likely going to work just fine somewhere else.

Drawbacks

• Maintenance nightmare – if for any reason you want to change a copied section, you have to change ALL the copies.
• Unorganized – there isn’t much organization to it. You simply create massive amounts of code to decipher after a while.

So, if there’s such a possible mess after massive code reuse, what’s all the hype about? Companies are pushing for code reuse, yet it doesn’t seem to lend itself well to long term maintenance, which is the majority of the time spent on any lasting application.

More realistic definition: Code reuse is allowing code that you’ve written to be accessible from more than one place. It can also imply that as a component, it’s accessible via a common interface to other components or applications. Though this may not be the best 2-line definition of the term, the key is that it’s far more meaningful than the literal definition. The following sections elaborate more on what code reuse really is.

(more…)