This is probably no secret to most, but developing is a craft. What are typical signs for a craft? Let me list the obvious:
- Not one piece of software is like the other
If you ask two developers to write the same software, the solution will be different. Even given the same software tools, there will still be differences between the results. Even more, if a developer wrote the same software twice, the results would probably be different. Every developer knows the phonomena of "If I would have to write it now, I would do it differently".
- Doing it for the fun
Most developers are developers because they enjoy what they do. They are in the are for the personal enjoyment. One of the reasons why open source works is because it offers people the ability to experiment and work on things they normally wouldn't be able to.
- Developers take pride it what they do
Closely linked to the previous point is this one. Everyone working in the field of development knows that developers take a lot of pride in what they create and have an aversion to creating what they preceive as "bad code". If project constraints (time, bad code structure, etc.) force one to do it that way, you'll always get an earful.
- Communication about new "techniques"
If one takes a look at advanced development books, you'll find that they have many basic solutions which can then be changed as the situation dictates. These templates - known as patterns - are communicated in forms much like surgeons do.
Surely there are many more indicators and examples, but I think this should illustrate my point.
So, if it is a craft, what does this mean?
As a developer, something to be careful of, are the inner workings stemming from development being a craft. Easily one starts developing things that are more "fun" then the ones that are necessary. This issue appears again and again in my blog posts, so I won't go into details here, but the principle counts: to any software construct, there must be a requirement calling for it.
Because development is a craft, this also means that experienced developers are by definition better. While this seems obvious, the difference is much more pronounced then on an assembly line for example. On an assembly line the performance of the individual has far less impact on the overall result then in a workshop-like setup which explains why experienced developers can command so much more income over inexperienced ones which sometimes struggle even to find a job.
This has lead to the rise of the title "Architect" as a differentiator between more junior and more senior developer and the job is to assure that the quality the junior colleagues deliver is acceptable. While many developers appropriate the title "Architect", a simple measure to assure a certain level of compareability would be to require a certain amount of years of work experience.
There are many forces out there trying to industrialize the process of software development. A very prominent example for this can be found in the Architectural Journal, No. 9 from Microsoft with the strategy of Domain Specific Languages and Software Factories which aims to adress exactly this issue.
The goal here is obviously to gain control of the production process by eliminating the dependency on individual performers and rely more on the process itself. At the same time, the designs should be standardized and consolidated creating exchangeable parts.
Principally every Library or API represents a standardization between products and every cross-plattform technology such as Webservices are like Industry Norms.
That these goals are not totally elusive shows the maturity which software has achieved so far. While there remains much to be done, issues like bluescreens or pointer-errors have vanished and software has become more reliable because of this. There is no doubt in my mind that this trend will continue, moving the skills necessary to implement software solutions for companies from Technology to Business. Things like memory model or calculation speed optimization with bit-shifting has moved into the area of unecessary or arcane. Of course the basics will continue to be relevant in some specific areas, but in the end, they will be a specialisation and a more industrialised process will be the norm.