New Article: Application Development is Dead

Home

News: New Article: Application Development is Dead

  1. New Article: Application Development is Dead (42 messages)

    This is the opinion of the author (Peter Varhol) and not TheServerSide or TechTarget, which has kindly consented to publish this. I’ve had the honor and privilege of presiding over the editorial content of TheServerSide.com for about 15 months now, and over the TechTarget Application Development Media Group and its six development-oriented websites for ten of those months as well. It is with decidedly mixed emotions that I announce that application development as we know it is dead. Who killed it? The cloud, that’s who. You know, that amorphous data center turned development platform somewhere in the sky. How can I say that, you are likely to ask? You’re still writing and debugging code, doing builds, sketching out designs and writing functional specifications. The cloud hasn’t affected that, even if you are deploying there. I contend that it will more and more over time. To explain why, let me reach back across my career for a moment. I’ve developed for DOS, VM/MVS, MacOS (the old one), and various forms of Windows. And I’ve done some tinkering on Unix and even VMS. I could work in any variety of different languages (it was long enough ago so that C or even Pascal were my choices), but I would have to learn and apply an API that was unique to that operating system. To some extent, at least, I could choose my target OS based on my knowledge and preference of its API. That was one of the appeals of Unix, after all. But we lust after abstraction, and there are an infinite number of ways of achieving it. In Java today, we have hundreds of different frameworks, depending on what part of an application we are working on and what we are trying to accomplish. In other words, we understand the problem domain, know our craft, and apply the best tools for each individual job. We choose, and to paraphrase the ancient knight in Indiana Jones and the Last Crusade, most of the time we choose wisely. It’s a vital part of being an architect or developer. Nevertheless, choice is starting to find itself in relatively short supply in development today. Sure, there still plenty of languages, frameworks, and code components, but we now have a few big IT players who are telling us what the “best” choices are. Microsoft says that Azure is what we want to use to deploy to the cloud, so if we are a Microsoft shop, we’re being pushed in that direction. As the economics of the cloud make more sense to deploy there, the “choice” becomes an imperative. You won’t be asked if you know C sharp, but rather Azure. Part of being an experienced and successful developer is making your own choices. Even if they aren’t the best ones, we learn from the experience, and it makes us better at our craft. But we still have plenty of choice in the cloud, you may say. Amazon’s EC2 simply provides capacity on demand, and I can decide how best to use it, and what languages and frameworks to use it with. Well, that’s true today, but putting my product manager hat on, I’m betting that Amazon is thinking that they need to build their own integrated stack pretty darn soon. And then you’ll be pushed in that direction. I have no inside information here, but the increasing rush of cloud providers to build an integrated application stack will not abate. How has this killed application development? We’re still writing code, after all. What it has killed is the ability to innovate through the use of other components and architectures. Do we have to deploy to the cloud? And even if we did, do we have to use the cloud provider’s stack? I’m suspecting that sooner rather than later private data centers are going to become a quaint anachronism. Sure, there are good reasons to presume that for security or integrity reasons, some applications may always remain out of the cloud, but I think over time we’ll see fewer and fewer reasons for doing so. No, application development is setting itself up to coalesce around a handful of integrated stacks, all running in a VM. We’re losing a part of our creativity; it’s being hauled away by the IT types who want homogeneity in their deployments. And they will get it, even if they have to force it on developers through the cloud. The primary good news out of all of this is what goes around comes around, and within a few years we will all be so stifled at the homogeneity of the integrated stacks from the likes of Google, VMware, and Microsoft that we will rebel, and create language and framework chaos once again. Hail to chaos.

    Threaded Messages (42)

  2. Re: phhhhhhhbbblt[ Go to top ]

    I’ve had the honor and privilege of presiding over the editorial content of TheServerSide.com for about 15 months now
    Someone has been presiding over the editorial content here for the last 15 months?
    It is with decidedly mixed emotions that I announce that application development as we know it is dead.
    The end of the world is coming in 2012 anyway.
  3. Please remove article[ Go to top ]

    It sounds like whatever the author perceived as "application development as we know it" is some wildly naive and imagined version of how the industry works. Please tell me the site was hacked and remove this article. This is the worst op-ed I've read in quite a while...
  4. Yes application development is dead along with new ideas so we don't need the Patent Office. Yes while you are add it shut down the copyright office too. Oh boy you guys are so funny and so wrong..Oh you say this is joke Nevermind ... :)
  5. Re: phhhhhhhbbblt[ Go to top ]

    The drivers for heterogeneity in the past have been business requirements, cost, non-functional requirements, developer ability... The cloud doesn't change that. Application development will be as dead as it was when auto-coding UML apps were launched. System admin, though...
  6. News of application development being dead are highly exaggerated. Ours is probably the only industry that is quick to call something as dead, the moment we see something new on the horizon. If it's indeed dead, then we adopt to the new ways, and if that can't offer enough jobs we find something else and move on. Even if applications are totally dead, it's not the end of the world!
  7. I remember somebody telling me that Perl was dead 10 years ago. Hah!
  8. It is in the graveyard. Zombies over feasting over it now. They have no soul.
  9. Dead?[ Go to top ]

    How about an article on how dead 'The Server Side' is?
  10. If you look at the proposed Sun cloud you might change your mind. They are taking a completely different approach. You will be able to pick your hardware and os from a shopping list thereby avoiding having to buy into any particular development or run-time stack. The only problem is that since Oracle's acquisition of Sun there doesn't seem to be much happening with their cloud initiative. It might wind up being a casualty of the acquisition.
  11. This is just an insanely un-understable non-cogent article.
  12. +10 to that
  13. Good article[ Go to top ]

    This is a great article. The world is changing.
  14. It's not so much the cloud as thin client that has crippled application development. Management saw it as the answer to a prayer - no desktop support required - and jumped on it before the platform was ready. We've spent years trying to cram the functionality of a fully featured application into a client that was designed to display a few textual documents - and we've had to adapt to it. With some of the new rich, or smart, client tools coming along now the pendulum could swing back as we find ourselves with a thin client platform capable of delivering a sophisticated user interface.
  15. TRUTH[ Go to top ]

    I totaly agree with the editor. The push to the clouds is already happening and more and more applications will be deployed on it. The developer will need to find arguments not to deploy in the cloud... And the logic is also rigth. with just a few vendors, each one trying to push their own stack, the developer will have less and less options to exercise his creativity. cheers mhct
  16. Re: TRUTH[ Go to top ]

    I totaly agree with the editor.

    The push to the clouds is already happening and more and more applications will be deployed on it. The developer will need to find arguments not to deploy in the cloud...

    And the logic is also rigth. with just a few vendors, each one trying to push their own stack, the developer will have less and less options to exercise his creativity.

    cheers
    mhct
    What does deploying in the cloud or in your basement have to do with application development being perceived as dead? You'll still develop the application to deploy whereever you please, right?
  17. Re: TRUTH[ Go to top ]

    The developer will need to find arguments not to deploy in the cloud...
    I have a great argument: PCI let me know when things are tight and secure enough for PCI to trust
  18. I have been seeing the architectural pendulum for quite a while now. Dumb terminals, Client server, three tier, then RIA. It's part of life - technologies evolve and so should we. Today we can have a computational power that was not even imaginable a few years ago, or a privilege reserved to CIA, FBI, or other world superpowers. There will probably be another phase of the pendulum; many companies won't see the cloud as the only option or cost effective and will turn back to their own data servers; for many small businesses out there, it is still a quite expensive exercise. The cloud just does not fit everything. Another point is the theoretical benefit of having so many frameworks. I am personally a bit fed up of having to deal with so many framework, most of them lame/badly designed/unfit for any purpose. Running on AppEngine does not mean you could not design a brilliant solution for your business; deploying on EC2 on the other hand leaves you total freedom over your choice of appserver/language/framework. So, may I come back to my code please?
  19. This is just a very badly named article. There is only so much any vendor can provide in terms of their custom frameworks. Example: when you run on AppEngine, you can run Grails on it. What does the developer have to know? Grails. Also, I don't see how this is radically different from what we've been doing all these days. It is not enough for a developer to just know Java/JavaEE, he also has to learn Spring, Hibernate etc which are highly vendor specific right? If you mean that portability is lost and you get tied to the cloud then you are spot on. Still, I have to agree with others. This article seems to make a premature and over generalized claim.
  20. This is a worthwhile comment, Dushyanth. My title was intended to catch people's attention. However, why does a cloud provider (other than perhaps Microsoft) have to provide a stack? Please let me continue to innovate. Let's keep EC2, rather than tell me the stack I need to write to. Ok, granted, I don't really need to write to that stack, but it is the approved stack of the cloud provider. Why do I need the approved stack?
  21. I don't really need to write to that stack, but it is the approved stack of the cloud provider. Why do I need the approved stack?
    Because a supported stack is theoretically ground tested on that cloud infrastructure; your stack, like someone else's may have incompatibilities, thus requiring support. Support costs, and support cost adds up to the cloud provider's total cost. If the cost raises too much, the cloud is not cost effective anymore, hence they lose competitivity and as a consequence business. Sometimes I feel like technologists are thinking about writing code as to playing in the yard rather than producing something that is cost effective and effectively giving business a competitive edge.
  22. What is an approved stack have to do with application development being dead? How is that different than working for large companies that have one or two approved stacks? How is that different from you choosing a stack? That happens before you write an app, you still go out and write an application. If you don't like a particular cloud's stack, go use another cloud and it's stack. There are reasons, at least at this time, why clouds provide stacks. Google app engine for example restricts certain functionality (though frameworks that rely on it cannot be used with it). They do it for a reason. One of them being being able to scale the application horizontally in a cloud. Using in memory sessions for example is prohibited due to that. So I really don't see an issue here.
  23. Mostly agree...[ Go to top ]

    I think the sentiment in the article (at least from my prospective) is that clouds really change the fundamental assumptions we've had for over 50 years in developing applications - that is that scalability is mostly a deployment concern. I know it's rather a simplified view but I think it really boils down to that... With clouds (i.e. running your applications on the clouds) things change dramatically. You implicitly develop on elastic hardware infrastructure with more than one computer (i.e. resource) in it and all the scalability considerations should be part of your design and implementation from the day one. You simply can't physically develop in any other way now! Look, 15 years ago very few people even knew anything about multithreaded programming... Today, it's an everyday part of our development. Changes brought by clouds are way more profound than that. Nikita Ivanov. GridGain - Cloud Development Platform
  24. Re: Mostly agree...[ Go to top ]

    With clouds (i.e. running your applications on the clouds) things change dramatically. You implicitly develop on elastic hardware infrastructure with more than one computer (i.e. resource) in it and all the scalability considerations should be part of your design and implementation from the day one. You simply can't physically develop in any other way now!
    I'd like someone to give me a concrete example of how a cloud forces me to develop in a different way. How is it any different than deploying to a local cluster? Sure the cloud provider may provide you the means to easily provision additional hardware, but that is not that much different than asking IT to do the same except than one requires more paperwork ;) I still develop the application, and it still has to support clustering. Who cares whether it is in the 'cloud' or in the company datacenter running on a 100 images/boxes. My previous cloud rant... http://blogs.citytechinc.com/sjohnson/?p=84
  25. Re: Mostly agree...[ Go to top ]

    Shane, if you app is working fine in the cluster I guess you have very little to worry about - but still some. Few examples of things to care about: - Nodes in your "cluster" can have different internal and external IPs; when accessed from the same cloud - internal IP should be used, when accessed from external cloud - external IPs should be used - amount of physical memory available to your application can change at runtime; will your app take advantage of this? - amount of physical CPUs (or cores) can changes at runtime; will your app properly support that? - Will your app be able to request additional (or remove) resources (memory, instances, CPUs, cores, I/O bandwith) when it needs? Just a few non-trivial considerations that you are bound to face on the clouds. Best, Nikita Ivanov. GridGain - Cloud Development Platform
  26. I fully agree that with the author that very soon from now, cloud computing will have a huge impact in the way we develop software. I think for small and medium sized companies it will become the dominant deployment model. But I can not image that the large companies I worked for, (like banks and insurance companies), will host their main apps outside. I don't think the have to. In the past sharing mainframe capacity was very common, simply because hardly any company could afford a computer (there were only mainframes then). The same will happen with cloud computing. I predict that within a few years it will be very common that companies buy complete in-house cloud computing solutions.
  27. .. t will be very common that companies buy complete in-house cloud computing solutions. That would defeat the economy of scale purpose , wouldn't it. I think that after the midsize companies go into the cloud the rest (banks etc.) will follow. The same happened with adopting open source. Yes data sensitivity is another thing. But economies of scale will win them over. And besides, sorry to say, but everybody is fed up with development anyway. It's a necessary evil for most businesses. The cloud is one more excuse to send things off to faraway land.
  28. Peak of inflated excpectations[ Go to top ]

    Funny... The author seems to be part of the Hype :-) Check the Gartner Hype Cycle: http://resources.emartin.net/blog/pic/gartner-hype-cycle-emerging-technology-2009.jpg What's on the "Peak of inflated excpectations"? Yes! "Cloud Computing"...
  29. Funny... The author seems to be part of the Hype :-)

    Check the Gartner Hype Cycle:
    http://resources.emartin.net/blog/pic/gartner-hype-cycle-emerging-technology-2009.jpg

    What's on the "Peak of inflated excpectations"? Yes! "Cloud Computing"...
    Why not quote your grandmother? Historically, she can't be more wrong than Gartner. ;-) BTW, according to Gartner we will have online video in 205 years! I can't wait! ;-)
  30. correction[ Go to top ]

    2-5 years
  31. Why not quote your grandmother? Historically, she can't be more wrong than Gartner. ;-)
    BTW, according to Gartner we will have online video in 205 years! I can't wait! ;-)
    Off-topic: Does anyone have any data about Gartner's record in terms of correct predictions. I have a suspicion that they are wrong more than they are right and when they are right, it's often because their prophecies are self-fulfilling. Or, does anyone know how they came to be so influential?
  32. This kind of article just is not funny anymore. Some blathering about changes in the industry and simply too little to back up the headline - or should I say nothing at all in this case.
  33. noone is dead[ Go to top ]

    application development as we know it is dead
    Who "we"? Application development "as we know it" dies every 2-10 years. For someone who started in sixties it's allready died like 10 times. The same for computers as we know it, cars as we know it etc. You know what I mean, it's became better.
    I could choose my target OS based on my knowledge and preference of its API
    Lucky you, the most developers was forced to use particular OS and I'm sure most of them hated it.
    Who killed it? The cloud, that’s who.
    And you know who killed Bamby? Sex pistols!
    there still plenty of languages, frameworks, and code components
    Dead right! It's perfect. You can get the business target much faster, provide the user with additional futures for no extra cost and learn from good-perfect 3rd party code. Isn't it much better, than to cook your own soup made of poor ingridients and spiced with (mostly) limited abilities? :)
    now have a few big IT players who are telling us what the “best” choices are.
    OK, they can tell me what they want, I still have a freedom to choose!
    Microsoft says that Azure is what we
    MS always said "use this". MS development was, is and will be like beeing in jail. So f*** MS and go J, like many do.
    But we still have plenty of choice in the cloud, you may say.
    What cloud? Forgett clouds, it just another hype on the one side and will not have a huge impact on art of developing on the other side. And by the way, will be not acceptable for plenty of users ever (security aspects -> inhouse insallation).
  34. I am sure it was not a desirable conclusion for you to suggest that application development is dead so it is probably not a hard sell to suggest that you need to rethink your understanding of the currents in IT. First, a cloud simply provides an efficient way of sharing infrastructure from the network to the OS with all the built in HA capabilities. It also permits pre-configured application components to be deployed on top of these pre-built infrastructures with little to no effort and in complex sequence. If anything, the cloud will encourage more creative combinatorial schemes. This brings me to my second point: the rapid growth of web service-based architectures is precisely designed for interoperability not vendor-controlled homogenuity. Of course, each vendor will have solutions in each category but nothing precludes those category solutions from interoperating except bad design. This brings me to my last point: understanding the term "application development (APPDEV)." If by APPDEV you mean a single front-end that does everything. Well, that has been dead for a long time. I would say that died almost the day that the web browser came into being. I consider APPDEV the delivery of cross-functional capabilities without limitation by device or UI or load capacity or extensiblity or speed of alteration. Under this definition, APPDEV is actually just in its infancy. Also, IT is not driving single vendor platforms. Business economics and larger vendor delivery of exactly the sort of interoperable systems are. As soon as smaller, more nimble companies catch on to niche's in the various business categories, you will see a rapid best of breed return so long as interoperability is not an issue.
  35. Outstanding posting[ Go to top ]

    +100
  36. I never understood why this deployment paradigm was called Cloud Computing. The only explanation I can give is that it was called like that because it puts your application on a cloud, very far from earth and reality. I guess you'll have to hire some indian guys, not to do developpement (because development is dead, and we will all die very soon), but to do the rain-dance if you want the rain to fall from the clouds. Most of the critical applications are written in old languages, it's almost impossible to get rid of them by reimplementing them. Having such apps on a cloud could be more expensive than you expect, so make sure to consider that when moving to the cloud.
  37. Cloud Computing is so 2008[ Go to top ]

    Forget cloud computing. The new thing is cloud development. You get an account with an offshore developer, upload your usecases, they scale the project to however bodies you need, then out comes the code.
  38. The only things we bottom-line are trying to accomplish are : storing data, controlling machines, and making people superfluous Only the techniques are different. Pffff..... And we still keep going on with it. Application development as we know it is dead ? If so, the reasons for it are: we are stupid and rely on money-hungry companies and people telling us we are yet to try a new technique. SOA for example looks a lot like modular development. I've never seen a company do THAT correctly. Yeah....and they're going to succeed with SOA. Kiss my ...!! We shouldn't hurry so much and maybe try to do things right for a change. I've never seen a system not being f#$@!? up by hasty solutions, incompetent programmers AND designers. Now it's the cloud (I don't know)?? Tomorrow it's some other holy grail....... So paraphrasing the knight in Indiana Jones and the Last Crusade: Will we ever become capable enough to choose wisely?? And for he whom has seen the movie: It's the humble, simple cup you have to choose.
  39. really[ Go to top ]

    I followed the first half of the article. Then it started falling apart. And the last paragraph makes no sense at all. "Application" development is so flawed that 'dead' should be a good thing. Let's hurry up and finish killing it so we can move on to small, heterogeneous, interoperable, testable, cloud-deployable components that work together to solve business problems in a much faster way that "developing applications".
  40. Hilarious content in itself ...[ Go to top ]

    ... but the REALLY funny thing is that people get paid to produce this kind of nonsense.
  41. Re: Hilarious content in itself ...[ Go to top ]

    Nah, I get paid whether I produce it or not. Given the choice, I prefer to work.
  42. Sounds familiar[ Go to top ]

    There are many developers who are already forced to work in predefined environment. I have been working for some time on the SAP NetWeaver platform which is a very closed environment. You work in the SAP NetWeaver Studio (eclipse 2.x based), no open source frameworks are supported, the MVC model is an SAP technology that's unknown to other developers (called WebDynpro), you don't even use J2EE components like JSP or EJB's. Everything is special SAP API's. You can't even design OOP or DP because you work mostly in classes that are automatically generated. The result is that many WebDynpro developers don't know the basics of Java or J2EE, and most of them never even heard of Spring, Hibernate or JSF or any other common java frameworks. Even the logger is an SAP logger and not the JDK or log4j logger. I found that my collogues don't know the difference between abstract and interface, many can't describe a standard HTTP request/response flow, don't know any JavaScript or AJAX, and even ORM is an unfamiliar concept to them. Let's hope that's not what's going to happen to "cloud developers"... http://www.shefertech.com
  43. I agree with Dushyanth Inguva in that the title 'Application Development Is Dead' is not correct for this article. The author is only trying to point out that with the advent and rise of cloud computing (and it's popularity is rising), portability will be lost and you will get more and more tied to the cloud with its few vendors. I also agree with Dushyanth's point that the article seems to make a premature and over generalized claim but IMO it could be a good reference for the prediction of future trends in software programming. Another interesting point the article makes (albeit indirectly) is the "standardization" of software programming. And what is assisting this trend is the very few vendors offering cloud computing facilities and the very few languages that can be used to build apps on the existing clouds. I have been looking forward to standardization in software programming for a long time now. How many times have we come up with apps that do the same thing (examples that come to mind include accounting, business and ERP applications, database software tools, language IDE environments) except that its written in "another" programming language or has the same set of features as all the other software in its category except one or two "additional" features which competiting vendors don't have? If you see one of the many comparison matrices for choosing ERP solutions, you'll know what I mean. I believe that sofware development and software applications should be converging towards one common standard rather than having so many ways of doing the same thing. The advantages of having one common standard is obvious - just look at Java and the JCP processes - "write once and run everywhere". That should be the goal. Obviously if we're going to have only one accounting or ERP software serving all the companies in the world, it should be the best of the breed. In software programming, having one common standard will allow near perfect programming portabiity and help to realise the "write once and run everywhere" dream. How is cloud computing relevant to this ? Well, for a start, cloud computing has reduced the number of available platforms, vendors and software programming paradigms used by programmers to write apps. This actually assists in acheiving the "one common standard" goal.