Architect’s Guide to Bootstrapping a

Software Project

About Me

About Me

About Me

Architecture: "The things that are hard to change"

This talk is about application architecture, not as much enterprise architecture.

The important stuff, whatever that happens to be.

Ralph Johnson

Overview

People

Process

Product

The Profit

http://bit.ly/1SdTRYG

Marcus Lemonis

serial entrepreneur

gazillionaire

Project

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

leads to a change in status.

And never forget the 2nd Golden Rule:

"He who has the gold, makes the rules."

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

but don't jerk 'em around!

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

Program management 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

Developers are generally engaged in tactical thinking about solving a problem in front of them...

without regard to the enterprise and architectural concerns

They should be thinking tactically while minding strategic goals

Architects know developers well

because we started out as developers

HBO's Silicon Valley

This background makes us ideally suited to

do it all wrong when working with them

"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

Yet, we may never meet a real user

When real users are unavailable

Construct a persona for a typical user

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?

We should always prefer a group of real users to personas

even though real users can be a pain in the backside!

Another thing about users is

they demand more, buthatecomplicated

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 ...

... do a great Big Bang architecture design

http://bit.ly/1Sp3nby

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

Favor an

evolutionary architecture

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 beconstantly 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 refers to the deteriorating quality of decisions made by an individual, after a long session of decision making. It is now understood as one of the causes of irrational trade-offs in decision making.

https://en.wikipedia.org/wiki/Decision_fatigue

Decision Fatigue

The risk of a wrong decision is preferable to the terror of indecision.

Maimonides

Technical debt’s effect on software development is roughly analogous to friction in mechanical devices.

https://www.computer.org/csdl/mags/so/2016/01/mso2016010066.pdf

Friction

When you keep hitting walls of resistance in life, the universe is trying to tell you that you are going the wrong way. It's like driving a bumper car at an amusement park. Each time you slam into another car or the edge of the track, you are forced to change direction.