IEEE – Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software
Space shuttle software was 420000 lines long with 1 error. It last 11 versions with a total of 17 errors. Commercial programs of equivalent complexity would have 5000 errors.
Craftsmanship is a solution to the problem of delivering robust, high-quality applications to users in a relatively short time for reasonable cost.
Software engineering is a solution to a different set of problems, involving life or safety-critical systems, real-time and embedded systems, and systems engineering projects. In these types of problems craftsmanship approach is not the best one. Incremental development and evolutionary delivery are not feasible strategies.
Good enough software is a logical extension of the ideas of software engineering
Software engineering makes us forget that what really matters on a project is the skill, knowledge and experience of the individual software developers.
Craftsmanship is not a rejection of science and engineering, but rather a subtle blending of man, machine, and knowledge to create useful artifacts.
Software craftsmanship is a mindset and an attitude, rather than a body of knowledge.
Working with masters is the best way to learn a craft.
Learning from each other is an essential part of software development.
Learn how to collaboratively deliver software is one of the key challenges new developers face when they start working on real projects.
Software development works best when the developer has a deep understanding of the requirements, design and source code.
Claims that good developers can pass the certification exams are made, but the hidden implication that passing the exam means you are a good developer is really the classical problem of confusing correlation with causality. The fact that a developer has passed a certification exam says nothing about that person’s ability to develop a useful application, only that he has learnt how to pass the exam.
The concept of a single, responsible engineer signing off the complete work is not feasible for software.
If a person became an apprentice to a great developer instead of studying for a degree, maybe the outcome would be even better.
Rather than being known for their degrees, memberships, or certificates, the real credentials for developers consist of the applications on which they have worked.
Enthusiastic beginners not only renew the craftsmen, but also challenge the craftsmen by bringing in new ideas from outside. The power of this synergy has to be felt to be believed.
One of the traits associated with true mastery of any craft has been humility. Master craftsmen are always willing to learn and are able to admin their own mistakes.
Master practitioners ask lots of questions and then deliver what you really need (as opposed to what you actually asked for).
The key questions is: “Has he infected his colleagues with his enthusiasm and passion for the craft of software development?”.
By reading and asking intelligent questions, apprentices will be able to pick up most skills without being formally taught.
Maintaining and enhancing live applications give journeymen the best environment for improving their craft.
Experiences developers should be involved in the creation of training courses for other developers.
Practise without feedback just reinforces errors.
In found particular interesting and challenging the following:
Software craftsmanship rejects the software engineering notion that it is impossible for one person to know the entire system. Instead, it celebrates virtuosity and talent.
One of the keys to high productivity is in-depth knowledge of the entire application
Working in a closely knit team where everyone reviews one another’s work on a daily basis means that, even without trying, a journeyman will gain a real breadth of experience about software development.
The software engineering metaphor makes us believe that software development is manual labor. It makes us believe that the division of labor is a good thing that should be used in software development. It makes us believe that there are standard best practises that everyone should adopt. This notion is not true, however.
By creating artificial specialities with narrow skill sets, software engineering makes it impossible for one person to understand the entire application. Rather than encouraging developers to cross-train so that they can understand all of an application, software engineering promotes the myth that what is needed instead is good documentation. Unfortunately, although documentation is very good for recording decisions and agreements, it is a very ineffective way of preserving and communicating detailed knowledge of how a software application actually works. Software engineering has given documentation a very bad name. Many projects practically run without any documentation because inexperienced developers rebel against this software engineering view.
Small teams produce better software.
Journeymen prefer to work in small team. There is little value in being part of a very large team, because their contributions are unlikely to stand out.
Software engineering fails to pay attention to the most important component of the software development process – the people. The most likely reason for this omission is that individuals show up only in small teams.
Technical knowledge is mush less important than the ability to integrate well with the rest of the development team.
If co-location is impossible for your project as it often is for truly global projects, you need to pay special attention to communication. Make sure that you take the time to gather people together so that they can get to know one another. Although travel costs may be high, they will be offset by fewer misunderstandings and much smoother communication when people return to their normal locations.
One really good developer is more valuable to your project than five average developers.
It is a good practice to reward exceptionally productive developers, because they make the difference between success and failure.
It might seem counter-intuitive, but designing for a single user is the most effective way to satisfy a broad audience. Develop a close working relationship with a small number of users, and then create the best possible application for these users. Then the application will be ready for release to the mass market.
Customers just have to start insisting on high-quality, robust software and choosing their developers based on their reputation for delivering that kind of software.
Craftsmen enjoy being able to delight their users with the speed with which they can make changes.
Craftsmen build their reputations based on the quality of what they deliver to their customers.
It is better to have a functional, rock-solid, minimal-feature release than an unstable, buggy release with features that don’t quite work properly.
Good developers know how long things take and are rarely willing to sign up for delivering the impossible.
It is hard to find developers with 30 or more years of experience. Few remain as developers for a long time. This exodus is a real problem.
You should encourage you developers to get involved in local user groups and technical associations.
Once a developer is confortable presenting locally, the next step is to start presenting at conferences.
Software craftsmanship values long-lived technologies and programming languages.
Very few applications have a planned life of less than five years, whereas few software development tools are designed to be stable over that time frame.
Why don’t developers focus their attention on becoming really good at using the existing tools?
Think long and hard about why you want to use a new technology.
Treat software as capital. Make maintenance a priority during the initial development.
Start making your applications testable.
If you are going to build in flexibility, make sure that it will be needed. If you cannot predict how much flexibility will be needed, then make the application as easy to change as possible.
Consider whether your development tools are likely to remain stable for the lifetime of the application.
The major challenge when designing for testing and maintenance is to build sufficient diagnostics and instrumentation into an application.
The challenge the software craftsmen face is one of keeping up with all of the evolving technology so that they can create high-quality, robust applications even when using bleeding-edge technologies.
Good developers are more valuable than their managers.
Craftsmen take pride in completion.
Trust the craftsmen you know to recommend other craftsmen.
Evaluate Craftsmen based on their reputations and portfolio.
Creating an orphan application is not a good way to enhance one’s reputation.