Engineering practices - concept map

[Mark Levison]

I'm working on a new blog post that helps people see the engineering practices, what they are and their relationship to delivery. 

- Are there practices I've missed that you would add? (Maybe Story Splitting?)

- Are there effects that I haven't added on the right?

- Is there any supporting text you feel I've missed?

- Missing relationships?

In another forum Chet and Ron - suggested Collective Code Ownership and Just Enough Design (as the antidote to BDUF). I will be adding them in the next few days.

BTW for once this isn't going to be creative commons, it will be copyrighted. However once its complete I'm open to friends sharing it, using with clients as long as the copyright remains intact.

Cheers

Mark

[Jon Kern]

Cool diagram — always hard to achieve putting what we do into a visual. So much context. 

Some feedback…

General:

Maybe when you say “engineering practices” you really mean *just* "software development”? I do not see enough breadth below for a comprehensive software application delivery  map.

Specific:

“No Branches” is a prerequisite? for refactoring is it?…. Wonder what I am doing when I think I am doing something called refactoring after my tests are passing? :-p

My teams and I do feature branches and then merge them back into the main codeline once they are reviewed via Pull Request.

No Branches sounds impossible in my pea brain. 

SIDEBAR:

I am not that skilled <facetious> or I am unaware of the practice that has no branch in a repo <\facetious>. I use Git. Pretty sure it requires at least one branch. As referenced here  I do Git Flow, not Trunk-based I guess (though it seems like a blend as our feature branches are short-lived because our issues are generally small, and we merge into the one branch that gets deployed (after CI tests pass… of course) :-))

For me I would say “minimize work in progress” tends to minimize # of branches in flight.

My ideal goal is always SINGLE PIECE FLOW. We do it once in a while.

I guess “QA” is specifically left off (BDD != QA)? Leave all the testing to automation? YIKES. Maybe you have a UX design process baked in somewhere… And you ensure all UI code is tested?

Where do you ensure the architecture is performant, secure, scalable to meet the needs of the customer?

As an aerospace engineer-turned-software developer myself, I tend to factor in the end state of the likely deployment to alter some of what I do upfront. If it’s just another run-of-the-mill application, then you can likely use a common approach and can skip this step. Probably because I cut my teeth on man-in-the-loop, real-time flight simulation software. And other stuff for DOD, like missile command and control software. When there are rigid performance constraints, I tend to ensure that the approach is vetted against the requirements before I get carried away slinging code.

I feel like there are some necessary startup processes to get you up and running quickly with a glimpse or vision of the product/end goal. And then some set of similar, or refined,  or slightly modified practices that carry on during the life of the main product development period. I liken it to getting the skeleton up and running, or the “tree trunk and main branches” upon which we can rapidly build out the app. 

This was my attempt some 6 years ago to add a dimension of “time”… some practices, etc.

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

github: https://github.com/JonKernPA

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Levison]

Jon fantastic as always to hear from you. Somehow it makes me smile that the three people to comment so far are among the earliest Agile people. Specific comments inline.

On Thu, Jan 17, 2019 at 3:47 PM Jon Kern <jonk...@gmail.com> wrote:

Cool diagram — always hard to achieve putting what we do into a visual. So much context.

I agree - not enough context ever. The key challenge I find it that often not appreciated the real benefits of the practices. You and I take for granted the importance of simplicity, readability, sharing of skills etc - most people don't.

General:

Maybe when you say “engineering practices” you really mean *just* "software development”? I do not see enough breadth below for a comprehensive software application delivery  map.

Yes

Specific:

“No Branches” is a prerequisite? for refactoring is it?…. Wonder what I am doing when I think I am doing something called refactoring after my tests are passing? :-p

:-) Ok - I don't mind being a provocative. I should have called it Trunk based (and we will update it). 

In the notes I will make it clear than some teams are also successful with pull requests and even short lived branches. I will share a draft of the notes later that will accompany the picture.

The anti pattern I see is long lived branches for all of the reasons that are way to obvious.

My teams and I do feature branches and then merge them back into the main codeline once they are reviewed via Pull Request.

No Branches sounds impossible in my pea brain. 

SIDEBAR:

I am not that skilled <facetious> or I am unaware of the practice that has no branch in a repo <\facetious>. I use Git. Pretty sure it requires at least one branch. As referenced here  I do Git Flow, not Trunk-based I guess (though it seems like a blend as our feature branches are short-lived because our issues are generally small, and we merge into the one branch that gets deployed (after CI tests pass… of course) :-))

For me I would say “minimize work in progress” tends to minimize # of branches in flight.

My ideal goal is always SINGLE PIECE FLOW. We do it once in a while.

I guess “QA” is specifically left off (BDD != QA)? Leave all the testing to automation? YIKES. Maybe you have a UX design process baked in somewhere… And you ensure all UI code is tested?

We agree BDD isn't QA and that test automation is not everything. I had to draw a line somewhere, there is a limit to what I can cover in one picture.

Where do you ensure the architecture is performant, secure, scalable to meet the needs of the customer?

As an aerospace engineer-turned-software developer myself, I tend to factor in the end state of the likely deployment to alter some of what I do upfront. If it’s just another run-of-the-mill application, then you can likely use a common approach and can skip this step. Probably because I cut my teeth on man-in-the-loop, real-time flight simulation software. And other stuff for DOD, like missile command and control software. When there are rigid performance constraints, I tend to ensure that the approach is vetted against the requirements before I get carried away slinging code.

In theory this capture by Chet/Ron's suggestion for Just Enough Design Up Front.

Performance Testing; Test automation etc need an addendum at the bottom of the picture to make it clear these are valuable just beyond what I can pull off.

I feel like there are some necessary startup processes to get you up and running quickly with a glimpse or vision of the product/end goal. And then some set of similar, or refined,  or slightly modified practices that carry on during the life of the main product development period. I liken it to getting the skeleton up and running, or the “tree trunk and main branches” upon which we can rapidly build out the app. 

Again the distance between us is small.

This was my attempt some 6 years ago to add a dimension of “time”… some practices, etc.

Is this referenced somewhere online - a blog post or something I can link to from both my own and also my library? (https://agilepainrelief.com/scrum-developer-resources-and-references)

Cheers

Mark

[Wouter Lagerweij]

Hi Mark,

I tried something like this a while back, with similar (though much less pretty!) contents, I think. I'll look it up when I get to a larger screen.

You might like having a look at Arlo Belsee's graph: 

http://arlobelshee.github.io/AgileEngineeringFluency/Stages_of_practice_map.html

It, also, looked better than my spreadsheet 😀

Wouter

--

Wouter Lagerweij          | wou...@lagerweij.com

http://www.lagerweij.com  | @wouterla

linkedin.com/in/lagerweij | +31(0)6 28553506

[Jon Kern]

Here is a link, Mark… I just added a simple blog post on my sleepy blog :-(

http://technicaldebt.com/hard-to-capture-fluid-agile-practices-in-a-static-graph/

Feel free to use as needed.

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

github: https://github.com/JonKernPA

[Mark Levison]

Jon - I promised a draft of my notes on "Trunk Based Development" - please note I've not asked my editing team to look yet so we will undoubtedly spot English errors - they rock at catching these.

Trunk Based Development

Imagine our English document – two members have been editing their document separately for a long time. One of them has been saving to dropbox faithfully every few hours. The other spends 3 days editing the saving document. Both have made many changes. Now the 2^nd writer will spend several hours reconciling their changes and there is fair chance of making a mistake or losing a key change. In software development this affectionately known as merge hell.

 

Some organizations “solve” this problem by banning refactoring. (Not kidding I’ve seen this and its effects).

 

Others move to a model called Trunk Based Development – all code is merged directly back to the Trunk every time a change is “committed”. In our world of English documents this would the equivalent of saving your document to dropbox every hour and ensuring you’re always working with the freshest copy. In the event you differ with a colleague the differences will be smaller and more rapidly resolved.

 

Other groups work with an approach called Git Flow - https://codeburst.io/trunk-based-development-vs-git-flow-a0212a6cae64 - where changes are reviewed by a second person before being committed to the main code base. With our English documents this would require someone to review all of the changes before they were shared back with the wider world.

 

This model can work with a caveat that the work needs to be committed and be reviewed/promoted rapidly otherwise the reviewer work can become stale.

 

The risk I have seen with GIT Flow is that changes can take days to get merged back to Trunk. It requires a very disciplined reviewer to ensure that changes are committed rapidly.

 

I recommend Trunk Based Development to my clients when they start.

--

Along with explaining Trunk Based Dev - have I given people enough of a hint around GIT flow?

Thanks for playing my game. Hoping for other comments as well.

Mark

[Rob Park]

Would it be too provocative to modify "are committed rapidly" to something more specific e.g. "are merged into trunk daily"?

Average branch lifespan should be < 24h is my point. 

@rob

--

[Mark Levison]

On Fri, Jan 18, 2019 at 10:39 AM Rob Park <robert...@gmail.com> wrote:

Would it be too provocative to modify "are committed rapidly" to something more specific e.g. "are merged into trunk daily"?

Average branch lifespan should be < 24h is my point. 

Thanks for the improvement. Back to working on the whole blog post which is rapidly approaching 3000+ words.

Cheers

Mark

[Tim Ottinger]

Except that daily is nowhere near often enough. We do four-step TDD: red, green, refactor, integrate.

You can build up integration debt faster than technical debt.

Skipping any of the four is iffy.

Less so, of course, if the team is very small and/or slow moving.

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tim Ottinger, Anzeneer, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileotter.blogspot.com/

[Mark Levison]

Which why my change was actually: This model can work with a caveat that the work needs to be committed and be reviewed/promoted daily (at a minimum, strong preference for more frequently) otherwise the changes can become stale.

At the end of that section I also make clear that I recommend Trunk Based Development to my clients. 

-

My goal was to acknowledge that Jon's approach is valid in an Agile world, but not what I recommend to clients.

Cheers 

Mark

[Rob Park]

I'm with you there Tim, but referencing the research in Accelerate, we're talking about _at least_ daily. I've just found "short lived" to be too vague.

[Jon Kern]

Good stuff… 

Gotta up my team’s game in this department. We’re not hitting the 24 hour mark :-(

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

github: https://github.com/JonKernPA