In this episode we explore the way that technology, tools and architecture can affect the product that you are building. As engineers do we need to think more about product side? As product marketers what can we do to understand how the technology choice informs or limits our product possibilities? How do we deliver software in an open source project vs how do we deliver software in a corporate banking environment? What are the constraints that we need to be aware of in our decisions and how the customer need informs that. How we need to enjoy what we’re building - and make sure that we continue to enjoy building it as an individual, a team or as a company.

Once again I really enjoyed recording this one and asking myself some hard questions. Perhaps you have more questions that from it? Please get in touch with me via the Software Delivery Club. I’d love to hear from you!

https://softwaredelivery.club

SHOW NOTES

Dave Farley - Modern Software Engineering (https://twitter.com/davefarley77):

https://www.amazon.com/Modern-Software-Engineering-Discipline-Development/dp/0137314914

April Dunford’s Obviously Awesome (https://twitter.com/aprildunford):

https://www.aprildunford.com/obviously-awesome

Rosegarden Linux Audio and Midi Sequencer and Notation Editor:

http://rosegardenmusic.com/resources/authors/

You can also download a compilation of my best blog posts in PDF form. I call it:

A Systems Approach to Software Product Delivery

Welcome to the software delivery club.

Every week, I explore different aspects of the business of designing and delivering

production grade software, talking about subjects that I find crucial to

good software delivery , as well as to industry experts about how they get to

keep their production software running.

I want to know whether they build or buy how they cope with new features

and product changes, how they keep the customer satisfied while

also making that engineers happy.

I'll also talk about what tools we like to use and which ones we don't

as well as tales from the frontline when it comes to delivering and

supporting production grade software.

Thank you for joining me.

Welcome.

I'm your host, Richard Bown.

This is episode 15, it's all about the crucial interplay between

product and engineering or what does building the product have to

do with the tools technology and the architecture that we use to design it.

It's been vacation time.

And that means I got to spend the first few days of this month, busy scheduling

a load of emails for my daily newsletter.

If you've not checked it out, then I thoroughly recommend that you do.

It's a daily thing, so I don't imagine everything may land with you, but at

least not straight away, but I think it's turning into a great resource for

those who think hard about the subject of software products and software delivery.

In fact, I'm going to create a digest of it all soon.

And make that available as a free download to give you a taster, check the links at

the end of this episode for more details.

In the meantime to read more about the newsletter and sign up for it,

you can go to software delivery.club.

That's dot C L U B.

Come along and see what you missed out on in the archives, and please sign

up , I promise you won't regret it.

I spent some of my holiday reading some books about software delivery strategies.

Not all of it.

It was a holiday after all.

Two in particular, I've been reading have been Dave Farley's "Modern

software engineering" and also April Dunford's "Obviously Awesome".

I've not finished either of them yet, to be honest, I was on holiday.

So I'll leave off making any comments about them at this point,

but they are two fascinating books.

And really useful for those building production grade

software for real customers.

We want to build software the right way.

But we don't want to build software that people ignore.

For me, the product versus the engineering in my view, doesn't really exist.

We are all people who need.

some kind of affirmant in our lives.

We want to make our creations strike a chord.

So to do both, to engineer and be a product person, is possible.

Despite what your job descriptions or the industry may tell you.

And reading both of these books really brought that home to me.

The older I become, the more experience I get, the less, I see

the distinctions between skill sets, particularly at a senior level.

For developers who are real developers.

For product people who see themselves as real product people, that's fine.

Keep plowing your furrough.

But if you see yourself as an engineer with a product vision, then for

goodness sake, run with that vision.

Don't be afraid to stand out.

This is the core of what I believe makes great software.

It's not enough to just build stuff.

Well, you have to have users.

You need to have a community in order to validate your ideas and your execution.

When I talk about software delivery strategies, I mean, everything, it

takes to get an idea from inception.

To production.

That's the span of software delivery.

It includes software development practices.

But also product development practices.

For many years now, I've been building software professionally i.e.

getting paid for it.

As well as building software on the side.

The side staff, the side projects is of course, initially always less profitable

or zero profitable and hard work.

I've been doing it for so many years now that indeed I got a bit bored

of just writing the software and now I prefer to talk about it instead.

That's not to say I don't code.

I do still, and I do enjoy it still.

And I still have a few big projects in me I think.

But I like to make sure that any coding I do is for the right reasons.

I prefer not to code if I can avoid it.

In fact, I got to the point a few years ago when I built a prototype

for something and then realized that I need to be able to support that thing.

And, spinning forwards thinking further down the line.

I decided not to take it any further.

The acid test being.

Can you see yourself committing to that business model for the next so

many years to make a success of it?

I'll return to this point again, at the end of this episode.

But I believe it's crucial for building excellent software.

While it seems kind of obvious .i.e you have to actually enjoy using

the thing that you're building.

Testing it and using it must give you something that you can't get

from something else, a thrill or a feeling that you're making something

worthwhile, something better.

I have an ashamed confession to make here.

I started working for a SaaS company and regrettably hadn't really used the

product in anger or enough detail before I started that in a pretty senior capacity.

When I finally got my training on how to use it, I realized

that it completely sucked.

What's worse is in my time there, we didn't manage to make it less

suckier due to debt, inertia, poor systems, lack of interest.

No one building the product appear to care enough that it completely sucks.

And that in itself was a major warning sign.

Okay, so what else have I built that I'm actually proud of?

Well, one of the first things was a big thing and it's still going.

It's a Linux, audio and MIDI sequencer and notation editor, a

mouthful, called Rosegarden.

A couple of friends of mine at university built the original in

1993 for one of their projects.

It's almost 30 years old.

I got into Linux around 95.

And, me and one of the other originators decided to put this to Linux at the time.

And then a few years later, it completely rewrite it.

I've always had an interest in making music.

And I learned sequencers such as Logic Audio and Cubase.

And so using this massive project as a basis for my enthusiasm,

for music, as well as for writing software seemed like a logical step.

We didn't just stop at doing MIDI we added audio.

VST support.

Uh, loads of different interfaces.

An extensible file format that allows sharing of device files

all in a massive project, which is still actually going strong.

The proof of the pudding is in the eating, as they say.

It's been an incredible journey for Rosegarden.

Tens, if not hundreds of thousands of downloads, perhaps even

had an extra zero who knows.

Many devoted fans across the world, and it's still there.

It's still in its niche, but still going.

I'd like to think that the current version.

Which in essence hasn't changed since we rewrote it in early 2000s is a

testament to the original design decisions we made, as well as some of the

engineering that went into building it.

It's definitely down to the tenacity and patience of many

tens of developers over the years.

In fact, the authors list on the rose garden website is 87

individual contributors long.

Year by year, new people have come into the Rosegarden fold.

I don't contribute much anymore.

The windows build a few years ago.

Some automation stuff and that's about it.

But what there is now is a wonderful community and there

is a need for it to exist still.

Therefore it exists.

Product development is understanding what your customer wants.

Software development is the practice of building and delivering that thing.

The decisions that we make at all stages of these practices.

Have impact and implications on the products.

And therefore the experience that the customers have.

There's a tension, always in building software.

The need to create something which scratches an itch, both for

the customer and the developer.

This has to be balanced with a viable roadmap to delivering features.

And this is particularly keenly felt when it comes to delivering open

source projects like Rosegarden.

I've worked on many pieces of software in the last 30 years,

both in and after college.

The most enjoyable and longest lasting pieces of software have

been planned, but not too carefully.

They have borrowed ideas and then reworked them and have also been

relatively technologically agnostic.

Bolting new pieces on as they grow.

Maybe rewriting sections in completely different languages.

In order to do this, a modular and flexible design must

be the core of what you do.

Having an excellent basis for your work, whether you build or buy the core is the

key to making it extensible in the future.

You need to keep your options open, listen to what your customers are doing.

And be able to add those features without having to throw everything away.

When we first discussed rebuilding Rosegarden from version 2.1, which was

the university exit version two version 3.

We were in the middle of an architecture discussion for quite a while.

I remember this was the time when the Common Object Request Broker Architecture

(CORBA) was particularly in vogue.

And we did discuss using that, thankfully, that didn't get very far that version.

I mean, we jumped straight to version 4

. Additionally backwards compatibility

supporting industry standards, all ensure that you appeal to a

wide range of potential customers.

In my professional career, I've also worked on many financial transformation

projects are banks and insurers.

These have often been based around a single piece of technology

or platform, which provides a business rules type approach to

data ingestion and transformation.

These are essentially smart or sometimes not so smart ETL tools.

That means Extract Transform and Load tools, which allows the developer to

transform large quantities of data.

At speed to provide defined outputs of data, taking some data,

munging it into another type.

In this case.

The platform is the modular approach.

It provides a standard interface to a whole range of data sources, such as

relational databases, text files, file streams, rest API, XML, et cetera.

These are all plugged into each other via a platform engine, which

provides a familiar language.

These machines we build are required to work quickly.

Optimized for speed at the database.

Or elsewhere.

This was crucial in a production system.

But also, it was crucial to make sure that the interfaces and the rules

applied were consistent and repeatable.

Therefore, there was a lot of testing required.

Deployment had to be redone, redeployment, retesting, lots of manual work everywhere.

This we learned to automate, even with some complex database systems,

we hand-built basic CI/CD pipelines.

ourselves out of the tools we found around us.

Even Ms.

Project got used as a basic front end for defining our scheduling

dependencies and automating out of that.

What you learn is when data integrity is vital, you need

to ensure that quality is high.

Quality can be improved by manual testing and deployment, but automation

of this makes it quicker, more reliable and less difficult for the developers.

So looking at this.

There is more engineering technique required in building something

for a bank, where you need predictability and precision, then

there is when you're building a creative tool for creative people.

There you need to focus more on features and extensibility.

Both need a minimal level of engineering, knowledge and capacity.

But the banking system will require more attention when it comes to deployment.

The same is true, of course, for the user base.

Finance systems have a relatively small number of users compared

to people who use music software.

Even those on Linux.

So the technology choice and the effort you make to test and deploy your code

must match the needs of the user base.

If your end customer is paying for your service to be always available and

always reliable, then you need to pay attention to testing and deployment.

You can choose, for example, infrastructure that will

grow with your users' needs.

Auto scaling on public clouds.

Possibly architecting for microservices.

And deploying into a Kubernetes managed service if your customer requires

that . If on the other hand, you have a single client and they need a rest

API for their mobile app , then just deploy infrastructure appropriately.

Your architectural choices will inform the speed at which you can move the

people you can hire and the functionality and quality of service you can provide.

Returning to the subject of the acid test that I mentioned earlier.

How do you know that your product idea is one that you will continue to commit to?

As an individual as a group, as a company.

You must get excited about what you do.

You must want to deliver real change to those who you support.

How can you commit to this?

We can be smart, us software types.

But we have to admit that we're not as smart as the product marketers.

The real product marketers know what the user needs.

And they are willing to put a bet on it.

They will build something that works.

Sure, as an engineer, you can stumble around and come up with a solution

that might fit a specific need.

You might get lucky.

However you increase your chances of getting lucky.

If you don't just blindly build stuff, but make an educated or

sometimes very educated guess at what will turn your customers on?

Walking that line, finding what works is the place we need to be

every day when we deliver software.

Because software doesn't sleep.

We need to change it, to improve it, to fix it when it breaks, to show

its compliance when we're asked, to secure it , to integrate it.

We are creating a living thing.

We commit to it.

Every day, we need to consider what this means to us.

And what this means to the customer.

There is so much more we can talk about here, about how we can measure customer

interaction, how they use our software.

But for the moment, I would like you to consider that technology and

product are two sides of the same coin.

You can't have one without the other.

And you need to be proportionate when you make your choices,

as they do affect each other.

I hope you've enjoyed the thoughts today.

I've really enjoyed thinking about it myself.

And I would urge you to get in touch with me via the Software Delivery Club.

You can go to the page software delivery.club and sign up for the

newsletter and also reach me on Twitter @richardwbown, that's.

B O W N or on LinkedIn or via my website.

Until next time, keep coding.

Keep dreaming and keep thinking software.