Developers are in constant search for greenfield projects because it allows them to be free of constraints. But over time, I started to appreciate the innovation found within working around constraints. The goal of this presentation is use two experiences in my career which highlights constraints which begged for innovation. Only on my retrospective of these developments, one can appreciate the true novelty in constraints.

1. Novelty in non-Greenfields
The case: pre-existing constraints
creates awesome engineering innovation
(why I became a software developer in the first place)

2. Defining
Greenfield
Projects
“In many disciplines a greenfield
project is one that lacks
constraints imposed by prior
work. The analogy is to that of
construction on greenfield land
where there is no need to work
within the constraints of
existing buildings or
infrastructure.”
-- Wikipedia
https://en.wikipedia.org/wiki/Greenfield_project

3. Greenfield Software Development
“In software development, a greenfield project
could be one of developing a system for a
totally new environment, without concern for
integrating with other systems, especially not
legacy systems.”
“Such projects are deemed as higher risk, as
they are often for new infrastructure, new
customers, and even new owners.”
-- Wikipedia
Pros:
• Fresh approach to a problem
• Modern development stack from “get go”
Cons:
• Harder to validate before delivery
• No documentation
• Unknown unknowns

4. Landscape of
Development Phases
1. Greenfield
No pre-existing code, no integration concerns
2. Rewrite
Tear down the existing code-base; refactor
3. Extending
New functionality for new use cases
4. Maintain
Refactoring with extending capabilities
(Concurrency, performance, support)
5. Life Support
Just keeping things around
0
5
10
15
20
25
30
35
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 Phase 7 Phase 8 Phase 9 Phase 10
Development Phase Effort
Series1
Series2
Series3
Series4
Series5

5. Rewrites
We have evolved a lot in the industry to embrace
rewriting our software stacks, and we usually
perform it on our edge-based systems.
• Bespoke backends to serve Front-Ends
• New Front-Ends
• Micro-services adhering to API Contracts (think
Swagger, and similar)
• Migrating may be harder… but is a consequence
of a new design.
• But one does not simply rewrite systems near the
eye of the storm

6. Goal: extend the current
codebase and integration of
various systems to compose or
extend new capabilities to users.
Challenges
• Pre-existing constraints
• Tension to create new
experiences and capabilities
Helpful Hints
• At least a partially solved
domain (probably mostly
solved)
• Documentation / Code to read
• Known unknowns
Encapsulating,
Extending,
Composing

7. API Switch
and
Encapsulate
System A System B System C
Objective:
- Unify the discrepancies between systems {A, B, C}
- Make source system agnostic to users
Lookup APIWhich
system?
Interact
Non-functional requirement:
- 99th percentile response in 1000ms
Observed: 99th < 400ms
Remaining budget: 600ms
Observed averages: 2,000ms 10,000ms 30,000ms

8. API Switch
and
Encapsulate
SLOW
Systems
which we
depend on
for data
Solution
1. Place a cache
- New problem: invalidation of
cached copy
- Kinks still apparent: Pioneer will be
taxed for being “first”
Cache Copy
2. Refresh the cache asynchronously
- New problem: Can’t scale because
downstream systems fall over 10x
concurrency (1million+ scans)
- Kinks still apparent: How to seed for
undiscovered “graphs” (pioneer)
Scrape CRON Job
Preemptive
scan related
graph nodes
3a. Preemptively discover the graph
- Remaining problem: Still can’t scale
3b. Prioritize refreshes on recent activity
Scoring
System
0
50
100
150
200
250
0 1 2 3 4 5 6 7 8 9
Score Decay
∫Future: What if Machine Learning could
preempt the next move?

9. Maintenance Support
Goal: Provide nurturing to a
system as it grows up to
experience more data, and more
consumers.
Advantages:
• Clinical in outcomes of metrics
• Domain and work is well defined
and understood
Opportunities:
• Stretching those statistics and data
gathering stories
• Adapt the system to new use case
behaviors

10. Once upon a time...
CMS Designs had cycle times of 3-4
weeks (± year 2008)
• Digital marketing just started to take off –
meaning more frequent design rolls
• Our clients (dealerships) needed to follow the
brand of their manufacture
• Cycle Time was still acceptable to business
Metrics?
• Google Analytics
• Browser benchmarking (IE <=7 was 90% of
the consumers choice)
• Number of events to rework required for
dealership customization
Cycle time reduced to one day, after six
month period
• Allowed more headroom to take on more
ambitious UX projects
• Browser performance outstripped mega-
digital agencies employed
How?
• Adopting 960gs, jQuery
• Enforcing stricter JS and CSS linting
• Continuously identifying high-value/low-effort
fruit which were ripe for improvement
• Repaying technical debt without asking for
permission

11. Life Support
Goal: gracefully switch off the
lights with no person left behind.
Challenge: change management

12. Share your
Innovation with
Others
Fall in love with the limitations of the
pre-existing systems, and enhance
and refine the domain knowledge.
Communicate your vision of bringing
innovation into the existing product
you work on.
Avoid seeking and wanting to label
the Frankenstein; nurture an
evolutionary framework