SmartBlog

Acceleration of the Ever-changing Development Environment

2009-07-14T11:35:00.005-04:00

It is hard to believe it has been over 10-years since defending my master's thesis.

Back in 96/97, the world had about 4-years of exposure to the commercial web ... it was already so clear that the impact on software engineering was going to be most acute to the development environment.

Consider this ... there was no major company nor major revenue-generating project built with Java back in 96. C# wasn't even in use in academia, much less any production system in the private/public sectors.

Jump forward to today. It would be boring and rhetorical to list the overwhelming number of new programming languages introduced since Java and C# were born.

Of course, core programming languages are only a slice within today's array of tech stacks. Even in tightly controlled dev team environments (and much to my dismay), I've come to expect to find developers using differing vendors/versions of compilers, IDEs, browsers, operating systems, app servers, collaboration tools, etc., etc. Imagine the number of permutations of development environments this presents ... and within even a single team that is said to be striving to accomplish a single primary goal: to produce a stable, predictable, and maintainable product.

And ... let's get to the point of this entry ... there is a clear acceleration of the ever-changing development environment.

There is no doubt in my mind, based on my consulting experience working with distinctly different teams on distinctly different projects each working with distinctly different development environments, things are getting even more complex. The amount of permutations is accelerating ... rapidly.

The impacts of this are scary. The productivity of a development team working with such distinctly different development environments can only suffer. Sharing experiences/tricks/tips/solutions with these colleagues, bringing new team members into the fray, picking back up on a project written a few months back w/o the original engineers ... these are serious and real problems. They are risks to every project I've been involved in for over a decade ... and they are rarely managed.

So, how do we manage this risk of the acceleration of the ever-changing development environment? Of course, there's no 'silver bullet' here, either. However, I believe it is manageable. Team leads *must* enforce a consistent development environment across their team. Yes, there will be those that are resistant to this ... there may even be those that choose to move on to other projects. IMO, good riddance.

This is a topic that I believe I'll discuss more going forward on the blog (since I've been such an avid blogger, eh?). In the meantime, team leads ... try this:

Before your next project gets too far into the PoC/prototyping stage, identify what development environment seems to be the most appropriate for the project kick-off. As members of the team begin to come on-board, ensure that they are competent with the target environment ... or at least capable of being productive in that environment in short time. Then, enforce it for the first iteration of the project. On each subsequent iteration, reevaluate the development environment ... ensuring it is still the best stack for the upcoming iteration. The environment *will* change, but it must be managed and must be consistently used by the development team.

Remember ... 85% of all software projects fail ... it stands to reason that chances can only improve by following this simple tactic. Till the next post ... happy coding!

Ajax4jsf Component Factory

2007-01-10T16:00:00.000-05:00

In 2005 and 2006, all of my clients where trying to decide what technology stack to chose for the “next gen” product. Sound familiar?

By now, most seem to have at least chosen to forge ahead with stacks based on .NET or Java. In my most recent engagement, the tech stack of choice was JSE5, JEE4, Hibernate, Spring, JSF, Seam, Ajax4jsf, Facelets - with an Oracle 10g backend.

Most recently, I’ve been focused on helping the client decide upon how to build their custom JSF components. The requirements for these components are as complex as they come - highly ajaxified, data-intensive, and MUST play well within the overall tech stack.

As we’ve come to learn, building enterprise-level compents to this complexity is not simple. More over, the landscape for JSF component development is in a state of radical evolution right now. Any company playing in this space is releasing versions of their products - or even new products - weekly.

Exadel has just announced the Ajax4jsf Component Factory. I was fortunate to get an early look (and help from the Exadel team). My initial impression is that it brings to custom JSF component development the simplicity found in Facelet Tag Files - yet - allowing the full robustness of standard JSF component development.

I should be working on components through the component factory for the next month or so. More to come on this subject!

Time to contribute to my own blog!

2007-01-02T19:44:00.000-05:00

For those friends, colleagues, and clients who know me best … you know I spend much time writing tech docs - from analysis to design, to general R&D docs - and way too many emails! Perhaps this blog will provide me with the outlet I’ve been needing all along.

I plan to spend significant time posting lessons learned, recommendations for technology choices, and to simply post what’s going on with Smart Binary.

Speaking of Smart Binary - this coming January 15th will mark 3-years for the company flying completely solo! Both Susan and I are greatful to the clients we’ve been fortunate enough to work with during these early years. We look forward to continuing to work with you in the future!