When you are communicating with your customers you encounter the fact that you have a completely different meaning for the same words. Software craftsmanship is needed because most software is painful to use. With a few exceptions most software that people have to use as part of their job is abysmal. Corporate applications are in the dark ages and seem to be getting more baroque and unmaintainable. We need to find a better way to deliver working software that is a joy to use. Some progress has been made over the recent years but we still have a long way to go.
The concept of software engineering is nearly 40 years old. It was born in an era of optimism. Man was going to walk on the moon. No matter what the problems there was going to be a technological fix. From manufacturing it was a short step to software factories. Factories are a great concept but it's not really a place where people need to think. Outsourcing is not successful, we're an industry dominated by anecdotes.
Standard software engineering practices seem to be designed to cause failure. Projects manager do not understand technology. "Senior developer" requires only 5 years of experience. Project plans ignore variability. Waterfall is "ideal". Testing comes last. People forget to think.
Craftsmanship is a necessary because software development is a high skill task. Talent and expertise are require to deliver software. Mechanical metaphors actuvely proven us from delivering great software that user like to use. Craftsmanship is a way to connect passion with excellence. But enthusiasm needs to be guided by experience. Apprenticeship is a traditional way of gaining mastery in many complex fields. A key part of this is to learn from other people typically from learning on the job with an experienced person. This only works for static environments because people need to agree on the content of the teachings while often the companies are pushing to get knowledge on new stuff.
We can still use the ideas from the apprenticeship programs. The basic idea is that a trainee should contribute to a real project. The best place to start out new guys is in maintenance of existing solutions because the turn over time is much shorter. We need a tool changes to allow experienced developers to review the patches before they are committed.
Too much software is developed without appropriate adult supervision. Alan Cooper hinted at a missing role in projects, there are plenty of workers and managers, no foremen. Supervisors are a key part of most organizations. We need to find a way to retain experience and expertise. We need to encourage senior technical roles that remain active on projects. Skilled developers should not have to transition out of technical roles to advance their careers. Team leads need to take active responsibility for the quality of what their people produce. Team lead need to be very active in coaching their people to improve their skills in all areas.
The sad fact is that many people on projects do not even know the basics of their day job. Small wonder that projects are stressed. Comp sci and sfotware engineering degrees do not seem to be effective. Not a popular sentiment but how else do we explain how bad software is these days? Part of the problem is that academia does not see that is has the responsibility to train the software developers. Amusing as it may be, the open source community is much better at training than most corporations. Once key difference is that corporations do not have known individuals who are responsible.
How can we developers improve ir skills? The pramatic programmers suggested that we all learn a new language every year. Reading books and code is also an effective strategy but you have to have the attention of applying the new skills to a significant project. Working with others however remains the best way to learn new stuff. Another thing that has to change is the way we think about software. We spend too much time writing new stuff instead of improving on the existing stuff.
Software is embodied knowledge and we have to act accordingly but it is really the members on the team that matters. Multi-generational teams are a good starting point. A team of twenty somethings has a great energy but old developers bring a breadth of experience to the task. Handoff to a maintenance team never works well. The team that created the application need to stay together to maintain and create future releases. Documentation is useful but it has to be written by the experts, for the experts. Anything else downs the team in paperwork.
You need senior people in technical roles with the authority to make decisions. Managers without technical skills should be transitioned out of IT roles. Many placed have a high turnover of techical staff. Technically competent line managers provide visible evidence that development career path.
Most projects are badly mismanage. Few projects allow time to think about the issues. Project requirements are rarely questioned. Manu projects are good response to the wrond problem.
WE need project managers to report to the project lead. The person who is responsible for the success of the project needs to lead the project. Admin staff can handle tracking the project schedule. The lead needs to focus on the big picture items and whether the entire team working well?
We need to evolve our designs instead of reinventing designs from scratch. We need more continuity in our teams. That the lead architecture leaves the company should not result in a complete rewrite of the architectures. Improvement comes from spending a lot of times with users. Many ideas that look like neat fail in the real world. Initial failure is OK as long as we learn from it. Better decisions are made by practitioners.
Having deep domain knowledge means you have to ask your users. You are not your user. Especially when you know what your user needs; remember that craftsmanship comes about through humility. We can always learn more from our users. Software is meant to be pleasant to use, if it isn't we are doing something wrong. We need to commit to improve our user's day job.
Classical books that all developers must read:
Prgrammers at Work
The pragmatic Programmer
Agile Software Development
Lessons Learned in Software Testing
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.