Architect’s Guide to Bootstrapping a 

Software Project

About Me

1st Career

About Me

2nd Career

Architecture: "The things that are hard to change"

Overview

• People
• Process
• Product

The Profit

http://bit.ly/1SdTRYG

Architects straddle the line

between technology and business

This guy was an architect

who didn't care about the business

People

Stakeholders

We may think stakeholders are like this:

... but the reality is far different

We can help them help us better.

We just need to manage their expectations.

Misleading stakeholders almost always

And never forget the 2nd Golden Rule:

Stakeholder relations

• Don't take stakeholders for granted
• Always think about their interests
• Work to manage their expectations
• Under-promise and over-deliver to delight them
• Over-promise and under-deliver at your own peril

Project Managers

Project managers may seem friendly

Like stakeholders

we need to manage their expectations

It's far better to be transparent and open

than surprise them a week before release

Their success is driven by the project

not making them look bad

We need to mentor them a bit in the tech

to decrease the risk of misunderstanding

Project manager relations

• Work to make them look exceedingly competent
• Help them understand the limitations of the tech
• Help them understand the inputs, processes and outputs
• Never use their technical ignorance against them

Developers

Architectural thinking is all about trade-offs

Architects know developers well

This background makes us ideally suited to

"I'm the architect and you're just a developer"

"I'll do the thinking, you do the coding"

"I'll stay away, then parachute in to save the day"

Just remember the first Golden Rule...

Most developers really want to learn more

Create a culture of learning to foster a passion for our craft

They don't want to be talked at or down to

Create a collegial culture where everyone contributes and benefits

Developer Relations

• Clearly define and honor architectural boundaries
• Don't make decisions that add to developer's pain
  • Be an active coder to experience & alleviate their pains
• Don't always try to prove you're the smartest on the team
  • Help make the developers smarter
  • Invite them make you smarter
• Every day, groom them to take your job
• Be the humble servant, not the master

Users

The sad user story

• We rarely use our own software
• BAs & Product Owners are often user proxies
• Stakeholders may act as user proxies
• We may never actually meet a real user

When real users are unavailable

Personas 

• Imagine a particular user of the application
• Be specific about that user's demographics and attitudes
• What does that user expect?
• What would delight that user?
• What would frustrate that user?

Another thing about users is

they demand more, but hate complicated

User relations

• Those pesky users make or break an app's success
• Get to know some real users
• Delight them when you can, but never disappoint them
• Help shape their expectations
• Remember: The customer is always right

Us

If I just think about it long enough, I can ...

Problem with an upfront Big Bang design is

we know least about the problem at start

• Loosely coupled components are deployed
• Features are released
• Application is about routing between components

Defer architectural decisions until the last responsible moment

Venkat Subramaniam

Physician, heal thyself

• Even if you are the smartest person in the room, don't keep trying to prove it to everyone

• Help define, then accept, limitations of your role
  • No one cares on which line you think curly braces should go
• Almost everyone cares why you made a particular architectual choice
  • Document justifications to avoid Ground Hog day anti-pattern
  • Accept that you will be constantly second guessed
• In the end, your job is to help make everyone else successful
• Be the humble servant, always grooming developers to take your job

Process

Decision Fatigue

Friction

Automation

development

Choose an agile development process...

Low friction, effective communications...

reduce # of decisions individuals have to make

Guide developers on patterns and practices

Choosing the right languages & frameworks

to help decrease decision fatigue

All developers not the same

• Some love JavaScript; others hate it
• Some love DevOps; others hate it
• Some love heads down coding; others love socializing
• Some love writing tests; others hate it
• Some will love you; others will hate you. 

build and deploy

How many environments?

Minimum of three: Dev, QA, Prod

What does "environment" mean anyway?

Continuous Integration / Delivery

https://www.openmakesoftware.com/images/ReleaseEngineer/CI-CD.png

reduces decision fatigue and lowers friction through automation of the mundane

Bootstrapping decisions

the power of hello world

HelloWorld.groovy

class HelloWorld {
    static final String DATE_FORMAT_PATTERN = 'MM-dd-yyyy'

    LocalDate currentDate
    String dateFormat

    String greet(String name) {
        name = name ?: 'there'
        currentDate = currentDate ?: LocalDate.now()
        dateFormatP = dateFormat ?: DATE_FORMAT_PATTERN

        String dateStr = currentDate.format(DateTimeFormatter.ofPattern(dateFormat)
        "Hello $name. Today's date is $dateStr"
    }
}

HelloWorldSpec.groovy

class HelloWorldSpec extends Specification {
    HelloWorld helloWorld

    void setup() {
        helloWorld = new HelloWorld()
        helloWorld.dateFormat = 'MM-dd-yyyy'
        helloWorld.currentDate = LocalDate.of(2016, Month.APRIL, 15)
    }

    @Unroll
    void "When providing a name, Hello #name will be output as #output"(String name, 
                                                                        String output) {
        
        expect:
            output == helloWorld.greet(name)

        where:

        name || output
        Jack || "Hello Jack. Today's date is 04-15-2016"
        null || "Hello there. Today's date is 04-15-2016"
        ''   || "Hello there. Today's date is 04-15-2016"
    
    }

    // more tests omitted
}

HelloWorldIntSpec.groovy

class HelloWorldIntSpec extends Specification {
    static ApplicationContext appCtx

    HelloWorld helloWorld

    void setupSpec() {
        appCtx = new GenericGroovyApplicationContext("classpath:Spring/Beans.groovy")
    }

    void setup() {
        helloWorld = appCtx.getBean(HelloWorld)
        helloWorld.currentDate = LocalDate.of(2016, Month.APRIL, 15)
    }

    void "verify Spring injected default pattern"() {
        
        when:
            String output == helloWorld.greet(name)

        then:
            helloWorld.dateFormat
            output == "Hello Jack. Today's date is 04-15-2016"
    
    }

}

What can I do with a few baseline decisions and three artifacts?

• Document architecture, setups, and justifications in Confluence
• Create JIRA epics and initial stories
• Develop API and UI locally using selected tools
• Verify Lint, CodeNarc, or other quality measurement tools
• Create a Git repo to house it
• Configure build job to build it and run unit tests
• Integrate Slack webhooks informing channel of build failures
• Verify remote build and test
• Manually do artifact repo provisioning, then script it
• Manually do DEV provisioning, then script it
• Configure job to run smoke tests
• ...

Product

Build - Measure - Learn

from the essential The Lean Startup by Eric Ries

The MVP [minimum viable product] is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.

 Eric Ries, The Lean Startup

What architectural pattern should we use?

Microservices bring complexity

Microservices bring complexity

1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up​
2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

​Martin Fowler, http://martinfowler.com/bliki/MonolithFirst.html

Always ask, "How will we test this?"

Measure everything

Process. Performance. Failure rates. Everything.

Minimize complexity by resisting RDD

Finally, work hard and play hard

Summary

• People
• Process
• Product

Questions?

Resources

• People
  • ​https://en.wikipedia.org/wiki/Stakeholder_management
  • http://www.romanpichler.com/blog/10-persona-tips-agile-product-management/​
• Process
  • ​http://gen2.ca/DBHS/Articles/TOK/DecisionFatigue.pdf
  • https://www.computer.org/csdl/mags/so/2016/01/mso2016010066.pdf
• Product
  • ​http://martinfowler.com/bliki/MonolithFirst.html
  • Building Microservices, Sam Newman, O'reilly
• Anything from Neal Ford & Mark Richards & Matt Stine & Venkat

All animated GIFs from giphy.com

Thanks!

Feel free to connect with me

• LinkedIn
  • linkedin.com/in/jackfrosch
• Twitter
  • @jackfrosch
• Email
  • jackfrosch@gmail.com