Skip to main content

Spec Driven Development

·762 words·4 mins
Mathias Færch Stensler
Author
Mathias Færch Stensler
Portfolio for the subject

Spec driven development
#

Spec driven
#

It is a type of software development approach where specifications are used to develop software. Ostroff, Makalsky and Paige describe tests and contracts as different types of specifications that are useful and complementary to building successful software.

Martin Fowler
#

in the post Martin examines SDD, a software development approach where developers write structured specifications before writing code with AI assistance.

3 levels of SDD
#

Spec First
#

Uses specifications primarily as planning artifacts before implementation.

Spec-anchored
#

Keeps Specifications alive after implementation so they continue guiding maintenance and evolution.

Spec-as-source
#

Treats the specification itself as the primary artifact with code generated from it and rarely edited directly by humans.

What is a “spec”?
#

A spec is described as a structured, behaviour oriented document written in natural language that guides AI coding agents. They can be described as rule files, guides or memory banks. They provide context across all coding sessions.

SDD tool kits
#

Kiro
#

Uses a lightweight workflow centered around requirements, design, and task documents.

Spec-kit
#

Developed by github, uses a more elaborate workflow with constitutions, planning files and structured templates.

Tessl
#

Tessl experiments with spec-as-source development, where specifications directly generate and synchronize code.

Key Critism
#

Current SDD approaches
#

Many workflows appear to heavy and verbose for everyday software tasks, generate too much markdown documentation that can be more bothersome than directly writing the code itself. Martin also questions whether AI agents reliably follow the instructions given. Agents frequently ignore, misinterpret or over apply requirements despite large context windows.

Replication of older software ideas
#

SDD tools may replicate older software engineering ideas, such as MDD, which historically struggled because of excessive abstraction, rigidity, and maintenance overhead. while LLM’s reduce some of the technical barriers limited by MDD, Martin worries that modern SDD systems may inherit both the inflexibility of MDD and unpredictibability of AI generated code.

My Thoughts
#

In my opinion i think that Kiro seems like the most approachable of the 3 tool kits we are introduced to. I could see myself using it in the future for projects im working on. by seperating the 3 markdown files brings a clear overview of design, requirements and tasks. But in reality i will probably just use claude to help me, as i have been doing.

Naur
#

In Programming As Theory, i am introduced to Peter Naur. Naur Argues that programming is not the production of code or documentation, but the development of mental understanding, a theory, of a how a system works and relates to the real world. According to Naur, the essential knowledge behind a program exists largely in the minds of the programmers who created it, rather than in the written program itself.

Naur describes programming as a deep human process that depends on intuition, experience, judgement and shared understanding. Documentation and source code are useful, but they can never fully capture what went on inside of the designers mind when creating the project.

Naur argues that successful software maintenance depends on preserving this overall, underlying theory. When programs are modified by developers who do not fully understand the concept behind the original design, the program will gradualy worsen over time.

He also critizes programming methodologies that treaet development as a sequence of formal procedures. No fixed method can replace a programmers ability to build understanding and recognize patterns or similarities between problems. Good programming depends on cultivating insight.

The essay presents software development as a collaberative activitty centered on human knowledge. programs only stay “alive” when there are programmers who possess and share the original theory behind them. If and when that understanding dissappears the program “dies” even if the code continues to run.

My Thoughts
#

I wholeheartedly agree with Naur on his theory and takes on programming as a whole. Programs are certain to die if the programmers behind the code forget what original ideas the programmers that came before them had. We have seen this happen multiple times in video games, social media platforms etc. For me, this theory doesnt only apply to software, but to ideas in general. One of my favorite games of all time is fallout 1, and the creator behind that shared his ideas with his team and they wrote a phenomenal story with interesting characters and ideas. As the series went on the main director and writer was changed and so was the very feel and essence of the future games, they are still good, but something definitely died with them.