Technologists have a tendency to focus on the technologies being used during a project. Many people would use the newest or most hyped technologies in order to stay ahead, or even just to use it as a learning experience. I have been in the software development industry long enough to know that technology is not an answer by itself. The business side of software development does not care about technology, it cares about getting work done.

As a good example of technology without a solution, we can look at the semantic web. I am a big believer in semantic technologies, and they will have their day, but there is not a big solution for semantic technologies yet. The foundation is still being worked on, and even big advocates do not talk about solutions yet. Disappointingly, I found a recent post that talked about the added value of the semantic web:

If I ask the question: “What added value(s) does the Semantic Web brings on the table?”. So, what are the benefits that companies and organizations would get from using the Semantic Web? I am pretty sure that after asking this question, I would get answers such as:

• You will instantly be able to traverse graphs of relationships
• You will be able to infer facts (so create/persist new knowledge) from other existing facts
• You will be able to check to make sure that your knowledge base is consistent and satisfiable
• You will be able to modify your ontologies/vocabularies/schemas without impacting the description of your instance records or the usability of any software that use it (unlike relation databases)

Obviously, if you need to talk about productivity, you are still not in the solution stage. Talking about what you will be able to do, as opposed to what you are doing, should be a clue that we are looking at a technology and not a solution. Don’t get me wrong, there are probably plenty of custom business applications that take advantage of semantic web technologies, but we are not really talking about several widely available solutions. Solutions and widely available applications for the semantic web technologies will come, we just have to wait a little longer.

This leads me to my next point, theory is not reality. How many times have you hear technologists start a sentence with “In theory it should work…”? When you look at software development, there is a lot of theory and much of your daily work is based on those theories, like the theoretical performance of a lookup in a HashMap. However, when theory is thrown around at higher levels, it starts to get concerning. This came to mind when I read a post by Rob Williams. He was reflecting on the 10 year anniversary of the Agile Manifesto:

The ten year mark just passed on the Agile Manifesto. It brought out quite a lot of commentary from the Tribe Elders, and frankly, most of it was depressingly insipid. It reached something of a crescendo for me reading Jim Highsmith‘s piece in Dr. Dobbs …, he basically said “we won, and if what we won ends up getting spoiled, blame the idiots.” … What, exactly was won?

Seriously, what was won and what was the competition? Given that agile is a process, and it gets spoiled by idiots, did you really win? Part of the idea behind agile development processes is knowledge sharing, meaning no single person should be the keeper of all of the knowledge about a particular area of the code. In theory, this should extend to the agile processes, like Scrum, as well. If that is true, can you really say that you have won if you things get “spoiled by idiots”? You may have won the theory competition, but in practice you need to make sure the idiots cannot spoil your efforts.

We see this in software development. In an application, you write code that should pass some QA, where this is just some unit tests or even a manual test plan. That code is expected to work for as long as the application runs. Developers know that they need to write code that is difficult to break, so there are plenty of guards in the application. Part of your job as a software developer is to ensure that the next person to touch the code can modify it easily and reliably. Code that is elegant but immensely difficult to maintain is not entirely good code. Part of the software lifecycle is maintenance, and you need to ensure that your code can be maintained. Idiots can always ruin the beauty of your code, but if it is easily maintainable, it becomes difficult for the code to be “spoiled by idiots”.

So, what was Highsmith talking about? Well, agile processes are now being heavily used and the waterfall model is being avoided in most cases. This is a good thing. However, the practice of agile still needs help. The theory of agile has been espoused for a decade, and now people need help implementing agile appropriately. We need to make agile processes easier for people to adopt, creating solutions that people can use to make the processes easier to adopt. Some solutions exist, and some have seen solid adoption rates, but until agile processes and solutions supporting those processes are in more than 80% of all software development teams, we still have work to do. Once the “agile solution” is assumed for a development team, you cannot say anything has been won.