I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Limit Your Points of Failure

03.16.2012
| 3642 views |
  • submit to reddit

When reading an article about Web Operations For Developers, one point in particular resonated with me. It discussed how you need to introduce new infrastructure carefully, and how each new shiny piece you add to your product adds another possible point of failure. I've always enjoyed utilizing new technologies and frameworks, but in the past year, I've started scaling back to basics. Why is that? Well, I'm tired of the problems that these new pieces can cause.

Let me illustrate this first with an example. If you've followed any of my posts, you'll have read my ravings about Titanium, which makes mobile development faster, cross platform and generally easy. This has been a great technology to get me going in my mobile app development adventures, but I'm going to have to call it quits. Why? I'm missing the real control. Sure, I can write a wrapper to provide some API/feature to my higher level framework. But is that overkill? Shouldn't I just use the lower level Objective-C or Java APIs in the first place? There are workarounds for almost everything, but workarounds take time too.

In fact, most of the frameworks that end up getting in your way provide an excellent starting point, and things look really good for a while. You've passed out someone who took a more traditional low level path. But for all that start-up speed, it's the last 20% that's going to slow you down. Who wins out in the end? Usually the guy who went with the more basic approach. Most of the time you'll need to go messing around with the internals anyway, to get things working as you'd like. 

While I'm sure I'm not the only one who has hit this type of problem, there's a lot of good productivity frameworks available - Roo and Play! seem to be popular. But I haven't used these enough myself to see if there are any flaws. 

So, are you someone who's been burnt one too many times by introducing a 'saviour technology' and adding a critical point of failure? What frameworks have you used that promised the world and caused you 12 hour days?

 

Tags:

Comments

Chuck Dillon replied on Fri, 2012/03/16 - 9:21am

"So, are you someone who's been burnt one too many times..."

Happily I'm not.  I'm the old guy that gets criticized for being overly-conservative and analytical by the younger folks that like shiny things.   As a result I've observed peers who ignore warnings from "old" guys/gals like me and then get badly burned by those shiny things.

It used to be that it took software engineers only a few months to realize there are no silver bullets and a few months more to realize that what looks like a short cut probably has a snake filled pit half way through.

These days it seems like a large percentage of developers are spending time building what amounts to a lego world of silver components.   All of the glare makes it hard for system developers to recognize that a custom silver bullet made from all these shiny parts is still a silver bullet that might go off in your face.

With all due respect to this forum, and others like it, a large percentage of it seems to be related to building or talking about shiny legos.

(Acknowledgement - "lego" is a trademark of somebody or other.)

Oleg Kozlov replied on Fri, 2012/03/16 - 5:25pm

Use of frameworks definitely has its pro's and con's. Every time you add 3rd software to your application - you risk introducing new bugs in your app or hitting a brick wall while trying to bend that software to do something it was not  designed for.

However, on the other side - frameworks can be real productivity boosters. They help rolling initial versions of applications faster than if all the plumbing had to be developed from scratch. If you want to develop everything by yourself  - you might end up lagging behind competitors who use frameworks to deliver their products to market faster . If your team has less senior developers and the application needs to grow   - you would want uniformity in how various use cases are implemented as opposed to having every developer producing their own solution using just basic tools. Without 3rd party frameworks - you would usually end up  developing your own framework  and that takes time and  causes additional overhead in training of new developers..

There is no silver bullet - you just have to decide what works best for your project and your team in specific circumstances.

I like the comparison of building modern applications to constructing something from lego modules. It definitely makes developing applications feel a bit like working on an assembly line in a factory.. However , I think this is just the next step in evolution of software development, just like many traditional industries had to move from craftsmanship to production assembly lines at some point.

 

Chuck Dillon replied on Mon, 2012/03/19 - 8:13am

I just want to clarify.  I was not questioning the value of any of the shiny legos when they mature to a reasonable level of reliability and supportability and when used as intended.  IOW, by no means was I saying that any framework, let alone all frameworks, are bad.

My concern is the same as Oleg's.  You have to do the systems engineering job before adopting a technology and it seems to me that SEs these days don't have sufficient appreciation of that.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.