Whenever Microsoft is gearing up to release new technologies, it brings corporate developers and ISVs from around the world together to discuss their implications. The Professional Developers Conference (PDC) allows Microsoft to get feedback from the community which will ultimately help drive adoption of its new technologies. And it allows developers to both influence Microsoft’s current technology designs and to begin thinking about and preparing for the upcoming releases. At this year’s PDC, Microsoft began publicly discussing upcoming .NET releases, a new version of SQL Server, and the next release of the Windows client. But as I spoke with attendees about their observations and plans for adopting these technologies, their answers reflected not only the future but also their current concerns and challenges with development technologies. Many of their concerns can be categorized in two main areas: security and agility.
As these are the people responsible for creating software that provides access to corporate information while also having to protect it, there was a huge amount of frustration among the developers to whom I spoke. They were frustrated with Microsoft for not reacting quickly enough to the threats against their core operating systems. Most developers agreed that Microsoft was moving in the right direction by making software updates automatic by using technologies like Windows Update and Software Update Services. But they didn’t think their management had the foresight or the confidence in Microsoft’s ability to create “clean patches,” so not many of them had implemented automatic updating of desktops and servers to protect them from hacks. Many of the developers said their companies were pinning their hopes on Microsoft’s next desktop release (called “Longhorn”) to be the platform that eliminates many of these security concerns. This PDC was Longhorn’s coming-out party, so many of them wanted to see what Microsoft was doing to create a more secure corporate desktop.
But in addition to looking for help from Microsoft, they were frustrated with their own companies for being “penny-wise and pound foolish” as it relates to their technology investments and security. I think one of the corporate developers I spoke to said it best: “My company expects me to write secure software on top of an infrastructure of Windows NT on the server and Windows 98 on the desktop. Those operating systems weren’t designed for an interconnected world. So I have all of these great new tools that I can’t use because we’re fighting security fires using squirt guns!” Even if Longhorn is the eventual answer, most developers knew that their companies could close gaping holes in their security coverage by simply adopting Windows XP on the desktop and Windows 2003 on the server. Moreover, this platform gave them new opportunities to introduce secure coding practices. For example, they could use Code Access Security to determine the rights to execute code based not only on the user but from where the code originated. Many advanced security features like these are only available to companies using the latest releases of both the server and desktop operating systems. And aren’t available to companies using other operating systems on the desktop (like Linux).
There was also quite a bit of frustration with the developers who create the viruses, Trojan horses, and other security hacks. Over half of the PDC attendees were foreign developers from Europe, Asia, and South America. Many of them expressed frustration with both the elements of their culture that saw these security attacks as justifiable, nonviolent acts against American software companies, and their law enforcement entities that appeared powerless to stop them. But frustration with the hackers didn’t affect their pragmatism when it came to defeating them. I spoke with developers from several companies that—although they were very Microsoft-friendly—recognized the value in mixing Linux and Windows technology to help protect their corporate assets. Their companies preferred to use Linux for firewall technologies because they deemed it “more secure,” and use Windows “inside the firewall” because it had better tools that helped them to develop applications faster.
Many developers also expressed frustration with their management for not giving them the freedom to develop applications faster. Interestingly, this frustration wasn’t about the tools that they had, but it was about the mindset of their managers. Many of their managers had “grown up” during the mainframe and early client-server era when a development project consisted of spending three to six months creating a system specification document followed by a six to eighteen month development cycle. Given the speed with which new technologies are introduced and the number of requests from their internal customers for new features and capabilities, they felt that their management had to begin looking at some different development methodologies that supported the principles of the agile development movement.
Agile development does away with the traditional waterfall development cycle. It's replaced by small, fast development cycles in which developers work closely with the end user advocates to create ever more complex prototypes that morph into the desired application over time. The resulting systems more closely reflect the priorities of their users and can take advantage of new technologies as they become available. Unfortunately, most managers see these not as tight development cycles but as projects that have the potential to spin out of control. It’s difficult to know “when you're finished” if the functionality and priorities are allowed to change as the project progresses.
So what’s the answer? Better tools. If newer tools, like those Microsoft previewed at the PDC, allow developers to create iterations faster and with fewer lines of code, then overall development time decreases and the ability to implement agile development principles increases dramatically.
Clearly developers are very concerned about the security of the platforms on which they deploy their applications, the security of the applications themselves, and their ability to create the applications using agile development principles. And most of the ones to whom I spoke don’t feel like their voice is being heard by their corporate managers. CIO’s should take the time to get the perspective of their senior development managers, planners, and architects and include them in the planning and decision making process for future infrastructure deployments.