Skip to content
Search

Software development process

lastmod 2025-05-24created 2015-03-0416 edits

A software development process (aka. software development methodology) is the process or structure needed to develop a software product. Similar terms are software life cycle and software process. There are several models of the software development process, each of which describes the activities or tasks required at each stage.

Deliverable documents

  • Software Development Plan (SDP)
  • Software Requirements Specification (SRS)
  • Software Interface Specification (IDD)
  • Software Design Specification (SDD)
  • Software Test Specification (STD)
  • Software Test Report (STR)
  • Software Version Specification (VDD)
  • Software Product Specification (SPS)

Methodologies

Methodology is bullshit: principles for product velocity

  • Principles for product velocity | GeekNews
  • Many companies slow down development by getting tied up in complex processes or lengthy requirements, but what actually matters is building the 'right product' quickly
  • Removing unnecessary elements from the product development process makes product development much faster. Building the right product is inherently a fast process
  • What slows product teams down are unnecessary elements such as process, the distance between decision makers and doers, and excessive specifications

[Principles for Product Velocity]

You need to 'do less'

  • In general, there is a tradeoff between speed and quality
  • Most companies set requirements and deadlines and treat quality as an outcome, but we do the opposite: we set the quality bar and think about what we can ship within 60 days
  • What matters is not trying to satisfy every requirement, but finishing only the important things quickly
  • Removing requirements and doing only the necessary work can raise both speed and quality
  • Elon Musk suggests a similar approach, saying "first, make the requirements less dumb"

'Idiot mode' often works

  • Take the 'midwit meme': the smart person and the idiot agree on a simple solution, while the average person makes the problem needlessly complex.
  • We often approach problems in 'idiot mode', trying to find a simple solution instead of overthinking.
  • When we made mistakes, it was usually because we thought too much; the simple way works more often
  • Asking yourself "What would I do if I were an idiot?" often leads to a workable solution

Not every problem matters

  • Only a few problems matter a lot. Important problems such as security must be solved, but not every problem needs to be solved.
  • For example, our mobile UI is not good, but we have not improved it because customers rarely use mobile.
  • Problems like this that customers do not care much about can be ignored.

Just build it

  • We have no process for product development. We don't do Figma mockups, PRDs, design systems, agile, OKRs, firm product roadmaps, A/B testing, growth hacking, etc.
  • Since our customers are engineers, we expect our engineers to handle product, design, and everything else
  • We prefer to build the product quickly and see how customers react

Rewrite when needed

  • Companies often think they can move faster the longer they put off technical debt, but we are not uncomfortable doing large rewrites when needed
  • Sometimes the fastest path to building the right thing is to build the wrong thing, realize it is wrong, and replace it with the right thing
  • If removing technical debt seems useful, we will do it

Outsource when possible

  • When possible, we buy solutions from external vendors instead of building in-house. For example, we generate our SDKs through a vendor called Fern
  • Of course, using vendors comes with significant upfront costs and limits freedom, but it is generally the right choice
  • Our engineering resources are very limited and expensive: a week of an engineer's time costs about $5,000. Considering opportunity cost, its value is much higher
  • Relatively few things are actually worth building

Don't hire

  • We don't expect adding people to increase the team's output. Hiring is slow and hard, and onboarding and people management consume time
  • It is especially hard to bring in capable people who can contribute without much support
  • So even though we have the resources to build a large engineering team, we do our best to stay small. This makes life much easier

Closing thoughts

  • We realized, to a degree we had not before, that product development should not take that long
  • If you know what customers need, have a strong team, and cut out distracting unnecessary elements, you can develop products at high velocity

See also

Favorite site

author Zer0 sitemap