This document discusses spec-driven development, which involves writing specifications for features in human-readable form, translating those specs into code (such as tests), and then writing code to fulfill the specs. An example spec is provided for a product tour feature. It explains that specs define what a user should see to satisfy a business need. The document also provides an example of developing a natural language to SQL query translator, writing specs for the basic flows and types of queries it should support before writing code to implement those specs.

2. Spec-Driven
Development
Vishnu Gopal

3. Where have you reached?

4. 1. You’ve selected an idea.
2. You have a product narrative.
3. You have experimented with moving parts
and reasonably know how to build the alpha
product.

5. Why?

6. Translating
business requirements
to code.

7. Spec = specification.
“This is what the customer
should see”

8. A general format for writing
specs is this.
[Customer Segment]
needs [feature/improvement]
so that
[a business need].

9. Example:
An SV.CO Founder needs to
see a tour on his first visit to
the dashboard so that she
can orient herself faster and
jump right into completing
targets.

10. Assuming you have this spec,
how do you
translate this to code?

11. Spec-driven development.

12. 1. You write the spec in
human readable form.
2. You translate that spec into code.
3. You write code that fulfils the spec.

13. 1. You write the spec in
human readable form.

14. Spec in human-readable form:
An SV.CO Founder needs to
see a tour on his first visit to
the dashboard so that she
can orient herself faster and
jump right into completing
targets.

15. 2. You translate that
spec into code.

16. This is Ruby/RSpec Code

17. 3. You write code that fulfils
the spec.

18. This is CoffeeScript Code

19. Steps 2. And Step 3. can be
done in any order.

20. Note: some TDD/BDD
adherents insist on writing the
spec first.

21. I’m ambivalent.
The important thing is to
have both.

22. The important thing is that both
the spec &
the code written to fulfil that
spec
are documented.

23. Example from Scratch

24. 1. You’ve selected an idea.
2. You have a product narrative.
3. You have experimented with moving parts
and reasonably know how to build the alpha
product.

25. “Natural Language to
SQL Query”

26. Basic Flow:
1. Customer sees a search bar
as the primary interface of
interacting with the product.
2. He types in queries in the
search bar and instantly sees
results.
3. The results are in tabular form
in the alpha version.

27. Types of Queries:
1. The customer cannot type
in anything like Google. This
is not a general search
engine.
2. Instead, he has a simple
syntax to learn to write
queries.

28. Examples of Queries:
1. Let’s assume 1 table:
students table with 3 fields:
name, location, marks

29. Example of Queries:
2. “students count”
SELECT COUNT(*) FROM
STUDENTS

30. Example of Queries:
3. “students count by
location”
SELECT LOCATION,
COUNT(*) FROM
STUDENTS GROUP BY
LOCATION

31. Example of Queries:
3. “students sum of total
marks by location”
SELECT LOCATION,
SUM(TOTAL_MARKS) FROM
STUDENTS GROUP BY
LOCATION

32. I’m ignoring a lot of the other
particulars here: like
login/signup, connecting a
database schema.

33. I’ve also experimented with
technology moving parts and
reasonably know how to solve
this.
1. Connect to DB.
2. Parse the query &
translate to SQL.
4. Execute.

34. Note: before we proceed
further, this is an incomplete
solution.

35. Focus on step 2.
1. Connect to DB.
2. Parse the query &
translate to SQL.
4. Execute.

36. [Code Demo]

37. Write Spec
Get a Red
Write Code
Get a Green
Refactor

38. Again: not important to do it
this way.
Important bit is to write
expectations and code that
satisfies it as pairs.