Why software is a craft [and also an industry]

The post argues that software development sits between craft and industry. It should produce dependable outcomes for businesses, but software products remain hard to predict in detail, even in narrow domains.

It says software people rely on a basic rule book made of skills, methods, paradigms, frameworks, and libraries, yet no single choice fits every case. The path is to use what is known, add experience, run experiments, and adjust as problems appear. Context and purpose matter.

Reading notes

#

• Software development is neither fully situational nor fully rule-bound; the answer depends on context.
• The medicine analogy is limited because software outcomes are harder to predict.
• Businesses want software people to deliver with as little surprise as possible.
• Problems will arise, but tech people are expected to handle them or delegate to someone who can.
• Software products are very unpredictable, even in domains like CRM and CMS platforms.
• You can have an idea of the destination, but the difficulties and best path are rarely well defined.
• Basic rules, skills, methods, paradigms, frameworks, and libraries help a software person know patterns and industry experience.
• Examples of choices include Rails or Django, native app or Cordova, Scrum or Kanban, mobile app or web app.
• When there is no single right answer, the path is to use what you know, add experience, try experiments, and fix things as they appear.
• Software development has many nuances: some parts are well defined, while others require you to build on what you have and jump ahead.
• The key is knowing the context and understanding where you are going and why.