Paradigm Over Technology

All too often in the software industry, if you are one that follows the latest tools and technologies, you risk getting pigeonholed as the guy who only wants to play with the latest toys. One of the typical sayings being that tools only accelerate your rate of failure (or success)..blah blah blah…

While this is true for some technologists, there are those that look beneath the surface of a technology and truly connect with the problems the new offering is attempting to solve. Most of the time in doing so, you see it is as coal slowly transforming into diamonds. And it is in this potential transformation that excites you as a developer. On the other end of the spectrum, you have the typical “old habits die hard” stereotyped personalities.

In my own past entries, I had mentioned new technologies in passing without fully conveying these. The assumption was that the underlying paradigms were obvious to any observer. But recall the other end of the spectrum? You need to convince those guys you aren’t a bandwagon jumping hippie.

By conveying your focus on paradigm and fundamentals, you can shed more light upon the new technology. No, I’m not talking about the evangelist regurgitations, but the real meaty substance. And ideally, an anecdote or two about life before this “paradigm” and life afterwards. People love war stories; so if you have the scars, feel free to show them. :)

Feedback

# re: Paradigm Over Technology

Playing with the latest tools and technology is fine, if you have your codebase, configuration management, and documentation in order. Too often the types of folks that like the play with the latest toys have horrible housekeeping skills when it comes to refactoring, code-reuse, and general code quality.

It is much more fun to go off and play with some pre-beta version of a tool then going through the code you hastily wrote in the last build and removing the hacks, dead-code, and redundant logic. 7/20/2008 10:52 AM | ICNet

# re: Paradigm Over Technology

That can be true in some cases and fits on one of the extreme ends. The point of the post is that you need to be pragmatic in your approach.

In fact, refactoring your code base is a perfect example of this. In some cases, there are happy mediums between sliding in a new component. You just have to be creative about how you are doing so and whether it is justified.

Granted, the non-greenfield development cases are the norm and this is where the technology idealism won't necessarily fit. But recall, it is NOT about the technology and more about the paradigm.

Take Functional Programming language features that have slowly made its way into C#. Developers will need to justify that the paradigm brings in business value in this case.

Another example being testability and having the justification for unit tests and mock object frameworks. Sure, it may be a big shift in a development shop's practices if they have never done it before. But it could bring considerable business value if the requirements are consistently iterated over; thus, requiring refactoring with a high degree of confidence. Such tools can also encourage the reduction in cyclomatic complexity of your methods in order to isolate bits for testing.

Whether it is in terms of readability, testability, maintainability, etc...
At the end of the day, it is about thinking creatively, judging the costs and benefits of how a particular paradigm (technolgy) and perhaps fitting it into your circumstance if it makes sense.

Why spend more money on a cordless power drill when you are strictly confined to a workbench in a garage with ample power supply? :)

If you truly understand the tools that are you at your disposal (i.e. learn about the new technologies and its underlying paradigm) and know when to use it, then you may be a better developer for it. This post is about differentiating those who marvel at the new shiny tool and those who take the time out to truly understand the paradigms.
7/20/2008 12:22 PM | yowhann

Yow-Hann Lee - Software Happens