A few months ago at a conference I heard something like "The only thing true measure of a software project is working code." While I cannot recall the exact quote, this was the basic gist and is very inline with "Agilist" thinking.
Principle 5 of the Agile Manifesto [ Note: I don't think they are in any specific order ] is:
"Working software is the primary measure of progress."
I heard it again at a conference this week: "We measure working software."
Read More
I had the pleasure to attend the 2nd Barcamp here in Raleigh-Durham at Red Hat's campus. After a great experience last year that provided me with new relationships and great inspiration, I'm pleased that the sequel lived up to the original.
Read More
Read More
The debate about sending IT work overseas has moved out of the political arena and turned into economic and structural discussion. This piece from IT News crystallizes that debate by talking about some of the mistakes organizations make outsourcing and some of the common challenges.
Outsourcing typically goes wrong when delays occur, you get poor-quality programming, and support and operational costs increase. These problems crop up when there’s a lack of skills, planning or infrastructure to manage the outsourcing relationship.
This paragraph in particular stood out:
“Most companies looking to outsourcing or distributed development continue to have unrealistic expectations or insufficient processes and infrastructure to adapt to this new development paradigm. Many simply adopt inefficient manual processes (e.g. more meetings, more travel) to manage the challenges of distribution, or turn away from the problem altogether, unable to see a viable, short-term solution to solve the pains of distributed development.”
That’s important because it gets to the heart of the issue: innovation.
6th Sense’s hosted an online debate this week on building software in a flat world. Among the points raised… the need to innovate and add modern practices to a discipline that’s hardly changed for decades.
Metrics are a vital component of any modern process because they help you establish a real-world infrastructure to manage outsourced projects. Metrics that are captured at the developers’ desktop in particular are the key to progress. They let you know what’s really going, so you can conduct due diligence on your current infrastructure and establish metrics to manage the new relationship.
As Delphi Group founder and Smartsourcing author Thomas Koulopoulos said during our web cast, these are early days for taking this modern approach, but things are clearly changing. Koulopoulos characterized it as the birth of printing: “We are at the very beginning of making a true science of application development and automation technology. We like to think we are much further along - [however] we are at the stage where Gutenberg invented the press rather then Heidelberg mass presses,” Koulopoulos said. Bring on the industrial revolution.
This week we heard the death rattle of a dying breed. Vodafone, the world’s largest cell phone company, signed a seven-year application development outsourcing deal with services giants IBM Global Services and EDS estimated to be worth more than $2bn. The companies will also provide application maintenance in eleven countries.
Five years back, mega deals were all the rage. According to separate reports from IDC and Technology Partners International (TPI) last month customers are now signing up to shorter contracts. Five to seven years, instead of seven to 10. TPI thinks we could even see sub-five-year deals. TPI said $1bn plus deals are at their lowest point in four years. IDC said such deals fell 3.1% in 2005. Mini deals are up: contracts worth less than $250m were up to 23% in 2005 from eight percent the previous year.
Smaller deals and more of them - a blessing and a curse.
Small deals mean suppliers must prove value and return on investment sooner than ever before. That accentuates the issue of how to measure and demonstrate value. Traditionally, project reporting software is used with other techniques. This can take time to bed down and fine tune… time service providers no longer have. Such tools are also notoriously bad at providing an accurate picture of events, which becomes a critical liability in short projects.
This trend is creating a growing demand to measure projects using real-life metrics gathered from the developers’ desktop and viewed in real-time. Such an approach provides the immediacy and clarity needed to measure and manage short-term engagements, which are the equivalent of a hurdle race versus the marathon run of mega projects. One minute mis-calculation or oversight in a hurdle race, and down you go - you’ve lost. In the marathon even if you go down, you stand a chance of getting back up, re-adjusting and coming from behind.
I had the opportunity to attend OSCON in beautiful Portland, OR this week and thoroughly enjoyed it. It certainly lived up to its billing as having the veritable who's who of the Open-Source community.
No other conference will you find so many representatives of the 'P' languages -- PHP, Python, and Perl. I've sadly ignored the 'P' languages for the most part. Sure, I've periodically used PHP to customize our web infrastructure (blog, forge, etc). I used Perl a long time ago when I work on large UNIX-based software systems, but I wouldn't consider myself a Perl hacker -- although the camel book from O'Reilly is one of my all-time favorites.
These languages are unique in that they inspire a passion for language that is very cool. When I'm at JavaONE, developers don't corner me and say, "I love Java," or "You've got to use Java for your application development -- you'll improve your productivity" or "It's impossible to write ugly Java code."
Java doesn't inspire passion. I've been using it since 1996, version 1.0. Every major application since 1996 that I developed, sold, and lived on was written in Java. Yet, I'm not passionate about it. I was in 1996, but I'm definitely not passionate about it now. Python's been around for almost the same time as Java, Perl's been around for much longer and developers are "giddy" about it.
This is not just a new thing. C# is very new and is quite nice. It was developed by a very cool guy, Anders Hjelsberg (also the creator of Delphi which has a very passionate following), and it is my language of choice for writing .NET applications. However, C# doesn't seem to inspire passion -- even among the .NET community.
Java, C#, and others (C, C++) don't inspire passion because they are the status-quo -- the languages used in the development of most business applications. They achieved this status through the support of major vendors. Sun and IBM hitched their wagon to Java, developed middleware and tools in Java to make it easy for big corporations to adopt. Same for C# and Microsoft. While there are pockets of Perl and Python in big companies, they are not the predominant force.
Look at PHP...it was extremely cool a few years ago. All the tracks at conferences were about PHP and the community grew. A year ago, IBM pledged significant support for PHP in conjunction with Zend, and now the excitement is starting to quell. No one cornered me at OSCON this week to tell me why I should use PHP.
Here's a graph illustrating the adoption vs. cool factor of languages. The challenge for the cool languages is how they increase their adoption without losing the "coolness". The typical pattern is illustrated on the chart.
I'm going to propose an alternative way for these languages to grow in adoption: prove it with data. Focus the passion on discovering ways to quantitatively prove that your language is better. I'll let the creative folks in the community determine which metrics are the appropriate ones to use. Proving that a language is superior can be all that's needed to make the business case to increase adoption and usage. Management at big companies (people that pay for things) need proof to jump to technologies because there is risk with it. IBM, Microsoft, and Sun mitigate that risk for them. However, your data can help make the case with or without the big vendors. And because the business case is made by the community -- it maintains the mystique, hype, and excitement around the technology.
I'll end on a challenge for you passionate Python, Ruby, and other hackers (sure Erlang, Haskell, and Lisp aren't excluded): Prove with our data that your language is superior. We'll gladly try out the first proven language on the next project we undertake and will publicly report on our progress. If there's a metric that we don't have that's essential for your proof, send us an email, and we'll see what we can do to add it.
What's the number one challenge applications developers will face over the next five years? According to analysts at Gartner, it's the same one the businesses acquiring those applications will face: integration.
"In the past, developers didn't have to make [applications] work together because we had people doing the integration," Roy Schulte, VP and distinguished analyst at Gartner Research, said during a session at the most recent Gartner ITxpo. "Now we've got applications talking to applications all over the place. And so it's something everybody has to do all the time."
"I cannot understand why this is not talked about more than it is," Schulte added.
He might not be hearing it, but developers are certainly talking about this app integration "challenge." Or at least they're thinking about it. Need evidence? How about Gartner's own stats, which show that 75 percent of all new applications being developed today use some kind of integration technology. Schulte pointed out that we can expect to see "integration logic" becoming another facet of the best-practices definition of applications, alongside presentation logic, business logic, and data logic. That's a huge change in application design. Need more evidence that developers and IT execs are thinking about application integration? Schulte's session was packed.
What developer working in the mainstream today could not know that the app he/she is building is going to be touched by other software? Even the schools are finally abandoning the old-style monolithic development styles, training their students instead for the fast-approaching service-oriented and event-driven world.
But Gartner does point out one worrying fact that may not be getting enough attention from the developer community: When you change the architecture of applications, you also have to change the middleware infrastructure running under those applications. "You can't do SOA using the kind of middleware you used for the past 20 years to build distributed applications," Schulte said. "Object request brokers, TP monitors, application servers, RPCs, sockets—-they're all great but they're not good for SOA and event-driven architecture. Therefore, you will have to change your underlying software infrastructure to use enterprise service buses."
The good news--or at least interesting news--is that stand-alone ESB products probably aren't long for this world. According to Schulte, it won't be long before most enterprises gain ESB functionality through other products that include them. The upcoming Windows Vista operating system, for example, includes the Windows Communication Foundation (WCF) architecture. "You'll buy an integration suite from Tibco, WebMethods, IBM, or Oracle with an ESB in it," Schulte said. "You'll be using an ESB because it really is the right infrastructure for SOA and event-driven architectures, but you may not be choosing it."
