In the last several years, there has been a dramatic change in the way many developers do their jobs. Agile methodologies, bolstered by new tools like distributed version control and enabled by systems like Ruby on Rails, have provided developers with an alternative to the monolithic development methodologies of the past. For developers working on web applications, these methods and tools are legitimate options, but are they here to stay? And what else is changing in how developers do their jobs? I explore both of these questions.
Adopting agile techniques
Agile methodologies are definitely not going anywhere. Agile methodologies are useful for web projects on teams with a tight-knit group of experienced developers and with systems that allow for rapid prototyping and iterations, and we are also seeing more stodgy systems like .NET and Java updated with new tooling and frameworks to enable Agile methods to be used. Even systems like Team Foundation Server are getting a fresh coat of Agile paint to help bring Agile to the enterprise.
You could argue that an enterprise zebra can't change its stripes, and you may be right. My time in the enterprise arena has taught me that, while a fraction of environments can embrace and run with new techniques, most of the time it is just folks paying lip service to the fresh ideas until management forgets about them. But as mainstream, big name vendors not only provide the toolkits for Agile, but show signs of embracing them (as Microsoft has on some projects), at least some teams will adopt these new techniques.
Incorporating user feedback
The drive to incorporate user feedback into the development process has become popular and will hopefully increase in popularity. With longer development cycles, it is easy for teams to become isolated from users and for decisions to have more time to calcify and become unchangeable. The new crop of tools like UserVoice make it easier for teams to provide support to users and collect feedback and incorporate it into their development plans. This has had the effect of compressing development cycles even for large products.
While some projects (like Linux distros and Chrome) have historically moved quickly, we are starting to see projects such as Windows pick up the pace. As customers' expectations become more accustomed to the speed of development of web applications, even on-premise software will have to keep up. Why? Because the new generations of web applications match the capabilities of native applications in more areas, and customers are quickly adopting them. If your native application can't come close to keeping up, there aren't many reasons reason for customers to stay with it.
Working in the cloud
The cloud is not just affecting the technologies that we bake into our products or how we deliver them, but our toolsets too. For example, none of our team's servers actually "exist," and we do not have an in-house IT team; instead, for less than the salary of one mid-range IT person, we have a number of servers from Rackspace that cover our production, development, and test environments. Our offices don't have servers racks -- they have a basic switch and routers connected to a reliable fiber optic Internet connection. The money we are saving on licenses, staff, and hardware can go toward hiring more developers.
Likewise, I see other teams using products like GitHub or Bitbucket for their version control, which lets them get rid of their servers and have a team of the best and the brightest from all over the country (if not the world) instead of being restricted to their local talent pool.
It is difficult to imagine any of these trends reversing any time soon. Although these new paradigms for working have their own issues and difficulties, they are working well for many development teams. These methodologies may not turn out to be the dominant or the only way work gets done, but they will become more prevalent.
J.JaKeep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.
Justin James is the Lead Architect for Conigent.