It’s not about code

I write software for business tool 

A stripped-down approach

to software developement 

No team workflow  

Soft skills beat technical expertise

Feature build only when business case exists

We build software to do the boring things instead of people doing it

The important part is not software

Software make results happens

Good software makes life easier

In business language = digital transformation 

How to produce the right outcome?

Understand business operation at its core

Understand how people operate

Understand how people interact with each other

Be as close as possible to decision maker / boss / stakeholders

Put myself is the shoes of the peole who will use the software

What works the best

Figuring out how the parts fit together

Understand how each part relate to which outcome

How much time we will spare

Which operation we can automate, and which we can't

What is the gain?

If it's not measurable

If I don’t fully understand the operations to be digitalized 

I don’t start architecturing and coding

Code is the mere expression of business requirements

We need tools to do the work

The client doesn't care about the latest tech

Those who writes checks only care for outcome

how much time spared

what amount of risk lowered

We should be very humble 

Sometimes our software is terrible

Makes people life miserable

We are tool makers

Not a lot of business problem need sophisticated tech

Software is here to serve business

It's a cog

Millions of line of code of COBOL have been in production for decades

How, being a one person team, I make this happen ?

Advantage: 

Disadvantage :

direct access to boss

technical matters must translate into plain language 

Onboarding is essential

Time to explain what custom development means

Starts small

Ship early

Go to great length to minimize the risk

Only work with very stable tech

Find the most stable,

reliable,

maintenable,

documented

tech which can do at least 90% of the job

Go for the robust solution

Know the known unknows

Assessment

never done it before

new libraries (doc is ok, bug ?)

what could go wrong?

Sophistication is the enemy of the prod

Where do I find satisfaction?

Discovering how business works - how operations relate to each other

Finding a “good enough” software model to work with

Finding ways to measure improvement

Best of all: ...

Don’t meet 

budget

time

scope (user satisfaction)

1 out of 3 digital project fails

Head management  “No value in digital project”

Which metrics to track

Know what would constitute a sucess

Before starting project

Business needs preditability

More than fast delivery

Date of shipment   –  not earlier the better

Don't break employees flow

I try to not give false hope

Never time estimate

No delivery date set in stone

Split project in chuncks

V1

V2 

V3

Business is risk adverse when purchasing IT project

Different if exploring new business avenue

Disrupting their business

New service offering

Not on new tech

Risk is here,

But still, don't put risk where it does need to be

not here

Communication, communication, communication

Onboard with project management tool (Trello)

“Friday demo”

15 to 30 min call

5 min recorded video of last feature

Recap email with milestone

Simple, strait forward UI

Business tool don’t go well with shiny animation

Employees need

UI they can trust

Uncluttered UI

Clear layout

Test is always a roadblock

Acceptance test

Needs to happen on customer side

Needs to happen early

=> Code in prod

Test on customer side will be late 

No matter what

Acknowledge and plan buffer time

Onboard more than one time

Leave debug state on (we're behind authentication)

People know how to screenshot

don't know to tell the steps to reproduce

People will asks

UI tweaks

Feature mismatch

Specifics asks like

“We need you to add this check box, control, thingy-thing”

“design smell” 

Go back to:

“what are you seeking as a business outcome?”

What’s your secret sauce?

Thanks :)