Software application development
This blog is intended to provoke discussion and exchange between like minded software application developers, engineers, architects, project managers - and keen hobbyists too.
Friday 7 August 2009, 9:09 AM
Lazy developers throw clunky applications over the wall
In a discussion based around neither a developer event nor even a press release, I got to chatting about this topic with Owen Cole, technical director at application delivery company F5 this week.
“A view we often hear is that necessity is the mother of good coding… and right now, application developers don’t need to write good code. Well, obviously they need to write an app that has all the features that they said it would include, but it needn’t be secure or even work that well on the network. It’s promoting laziness amongst coders because they know they can rely on a piece of tin - an application firewall or application delivery controller - to make their costly, complex app actually work when thrown over the wall to the network guys,” F5’s Owen told me.
We played around with several analogies at this point. Would a cook present a complex dish without tasting it first? Would BMW build a new supercar without putting it through its paces around the Nürburgring? Would you really build an application to handle intensive data flows for the retail market without running several batches of dummy data through it first to see if it will hit meltdown during the pre-Christmas rush?
Owen pointed out that while application acceleration devices may be used as part of the pre-flight testing process, in reality they do nothing to make application logic execute faster. They optimise TCP and HTTP/S protocols, they offload certain functions from the app (like SSL) and they accelerate the delivery of application data, but really, it’s only their ability to perform caching that really helps developers.
But could this lead us into yet another developer laziness crevice?
“What’s interesting about this point of view is what it also implies; if developers knew the performance of the app they are developing will be helped by an external piece of hardware, they’re not going to be as concerned with writing efficient code. This is a problem that can’t be affected by the solutions implemented to improve end-user experience or stability… but no technology can fix this – it’s a problem with the developer,” said Owen.
It’s no surprise I guess to hear that an application delivery company like F5 being vocal on this subject. IBM’s Rational cognoscenti often talk about ‘throwing apps over the wall’ in the context of how great automation their tools are at helping this process happen smoothly in a neatly debugged way. I contend that it is refreshing to hear the subject discussed in this negative (but yet leading to positive) manner instead.
Is this a reality then and do developers view the operations team as a bunch of losers? I heard a developer say that to me off the record at an event not so long ago. Does F5 have the right take on coding reality - and does it position itself in the right place to improve the delivery process with products like its TMOS platform for app delivery over a network?
PreviousComments on this post
It's an inflammatory approach for a vendor to generalize that developers are 'lazy', and that the poor old ops guys have to save the day with a 'piece of tin'!
In reality, developers are charged with delivering functionality and product changes to a specification, often under time pressure. Benchmarking, scalability and security are often not a key part of the specification, and it can be very difficult and time-consuming to test and measure the real-life performance of an application before it is deployed.
In practice, the ops team need to rely on traffic management technology like Zeus' ZXTM or F5's BigIP to address application delivery.
These products are much more than just load balancers. A traffic manager changes the environment that an application runs in; where most applications run poorly in real-world situations (slow, lossy networks; lots of idle connections), a traffic manager puts the app in the network environment where its full performance potential can be achieved.
A traffic manager also contains a collection of techniques that those vendors have developed to improve the scalability and performance of an application - session persistence, caching, rate shaping etc that a developer can rely on rather than having to implement the functionality themselves. Traffic managers developed by network-focused vendors tend to provide techniques that are tailored to the language and challenge that network ops teams face; systems developed by application-oriented vendors address head-on the challenges that apps guys face and speak their language.
A key problem I see when I speak to organizations is that their investment in traffic management can be locked away in the datacenter, inaccessible to the developers who can extract the best use from it. A easily-deployable software approach (think virtual appliances and cloud computing) is more accessible than a piece of mission-critical tin with an organizational firewall surrounding it.
