Software+

What is Regex

Regex stands for Regular Expression. It is a string of text that allows you to create search patterns that match text. For example this regular expression will find text that starts with "Australian" and contains the number "2023": ^Australian.*2023.

The beginning of that example has an anchor, ^ which anchors the "Australian" to the start of the text.

Just after "Australian" is a dot . which is a character class that matches any character.

The dot is followed by a star * which is a quantifier, which says 0 or more of the previous character.

Finally there is the "2023" which matches the exact character sequence 2023. The 2023 can be anywhere in the text after "Australian".

When we say character we mean any letter, number or symbol. Any thing you can type is a character including, for example a space. A Regex will normally only match on a string up to a new line (or character class \n).

The regular expression ^Australian.*2023 will match the following text (often referred to as strings, or strings of characters):

Australian Open 2023
Australian Parliament Committee hearings 2023-2024, Canberra.
Australian zimmerflex-#202344777662AQ-z

It won’t match:

The Australian Open 2023.
2023 Australian of the year.
Australian of the year 2022.

Regex Components

Anchors

anchors are used at the begining and the end of a string or expression.

^ Use to specify the beginig of the string or expression.
$ Use to specify the end of the string or expression.

e.g. ^Fred Fintstone$ would match a string that is only "Fred Fintstone" with nothing before or after.

Quantifiers

Quantifiers specify how many of the previous character, character class or group of characters you want:

* Finds 0 to more. e.g. fa*b finds "fb", "fab", "faaaaaaaaaab"
+ Finds 1 to more. e.g. fa+b finds "fab", "faaaaaaaaaab"
? Finds 0 or 1. e.g. e.g. fa?b finds "fb", "fab"
{n} Finds exactly n characters, e.g. a{3} finds "aaa".
{x,n} Makes a limit of characters (From x to n). e.g. fa{1,3}b finds "fab", "faab", "faaab"

Grouping

You can group a sequence of characters together for a purpose. Regex has a notion of a capture where the pattern within a capture group can be used in a result, for example when you want to find and replace a string, we won’t cover that.

Groups are used for matching a sequence a number of times, or creating a set of sequences that could be matched. A simple set of Parenthesis around a sequence of characters e.g. (cat), creates a capture group that can then have a quantity added. Examples:

shrodinger’s (cat)? was here matches "shrodinger’s cat was here" and "shrodinger’s was here"
the (.at)+ sat on the mat matches "the cat sat on the mat", "the ratcat sat on the mat", "the #atgatpatcatmatfat6atbat sat on the mat"

Groups can be split into OR blocks using the pipe special character |, for example:

the (cat|dog) was here matches "the cat was here" and "the dog was here"
the cats? (was|were) here matches "the cat was here", "the cats were here", "the cats was here"

Sets of Characters

You can define a range or set of characters that could be matched by putting them in square brackets. Unlike a group that defines a specific sequence of characters this says any of these characters, so [CRM]at matches "Cat", "Rat" and "Mat".

The set of characters can be represented as a range, for example:

[1-3]0 all the numbers from 0-3, matches "10","20","30"
[a-z] matches all lower case letters from a to z
[a-zA-Z] matches all lower and upper case letters from a to z

You can put a ^ at the beginning of the set to not match this set of characters, for example:

^[^:]* match everything from the beginning of the string except : which is useful for search and replace. If you had a string "2023-05-23 12:52:45" it would match "2023-05-23 12"

Shorthand Character Classes

There are shortcuts for sets of characters called character classes which just define a set of characters to match. We met the . class in the introduction, which is every character.

. every character except for new lines
\n the new line
\t a tab
\d a digit (0-9) same as [0-9]
\D NOT a digit (0-9) same as [^0-9]
\w a word character (latin) same as [a-zA-Z0-9_]
\W NOT a word character same as [^a-zA-Z0-9_]
\s spaces of any kind (space, Tab, new line)
\S NOT a space (space, Tab, new line)

There are many more see https://www.regular-expressions.info/shorthand.html

A complete guide to Regular Expressions can be found at https://www.regular-expressions.info/

Fast Agile with less ceremony

SCRAM is a hybrid between SCRUM and Kanban designed to work better with remote or disparate teams. It does away with processes that confuse people (story points anyone?) and tries to remove the religious ceremonies and focus on the vibe :-) We don’t anoint a Scrum Master either, since their role has been confused with project manager far too often. We’ll settle for Team Lead whose job it is to help the team, they’ll have responsibility for solving blockages, such as missing information. As per traditional Agile, the Team Lead role can be shared or rotated through the team.

Essence of SKRAM

As open as possible:

Communication and openness is the key to success in life. The moment you lose real openness, and silo information, you’re making it very hard to succeed. The quickest way to demotivate a team is demonstrating a lack of trust, and not being open does exactly that.

Openness leads to good communication.

Have you ever had to wait while sharepoint asks a manager for permission to access a document? Then had to do that every time the document gets updated? Were you disheartened?

Sure, you need controls, but you need to trust your team too.

Asynchronous processes:

Ceremonies with everyone in a room are for special events, reduce meetings to events where a solution, outcome, task list can be created quickly with less confusion.

Promote good documentation first:

Good documentation of stories and end to end goals and use of links removes the need for synchronous communication.

DO NOT USE WORD or any other word processor. Wiki’s and asciidoc/markdown promote content over style. Documentation should be minimal friction to get ideas across.
DO NOT USE TEMPLATES as they lead to information poor content. i.e. default content in templates. You can use prompts for specific information (sometimes called scaffolding) if it is always required.
DO NOT stick everything in a table. Tables are for tabulated data, not structure.

Promote automated tests and test-driven work:

Use tests as the basis of documenting and defining Tasks, Stories and Features.

Daily Stand-up:

A daily stand-up that is short and to the point is essential for team communication. You need to pass on the base info of what you did yesterday and what you’r working on today, that’s enough. A "Stand-up" can be async in chat where time zones are an issue, but try to have a synchronous stand-up where possible, even if not every day.

Continuous retro (it’s just story discovery):

A board with columns “Arrgh!”, “Woo!”, “Try…”, “yup” and “nup” when something shits you put an Arrgh! story in the Arrgh! column, the argh story gets suggestions which you can “Try…”. If Try… works put it in the Yup column, else the nup. Woo! is for things that are working well, and a story/use-case where it worked well. Yups/nups get put into doco.

Sliding sprint window:

look at what was completed in the last two weeks to determine velocity on a daily basis, which can be graphed to see if there are issues.

Estimate gut feel:

To estimate a task, all people in the team give a gut feel of how long this would take in days, do not over think it. Average the teams individual estimates, that’s the number.

You can estimate what will get done using how many estimated days got done in the last sliding window period continuously, and graph it. (you can now overlay the graphs)

Kanban backlog but:

Use a backlog of prioritised tasks, but we define how tasks get on the backlog to be another work flow (or kanban board set of states):

Story development → task analysis → estimation → priority → backlog. (see To the backlog!).

The whole team is expected to have input (work on) all the pre backlog stages. Time should be set aside regularly to do this, though when starting out you may need to spend most of your time doing this.

Dev workflow

Basic Task states are:

Backlog ↔︎ in progress ↔︎  stuck → done (done means tested)

The in progress state has sub states:

Developing tests → Developing solution → Reviewing → (repeat or done)

Stuck tasks can be sent back to the Story development pipeline if developers discover a problem.

Continuous Cycle

Day to day developers pick tasks from the backlog and do them. They should mostly pick the highest priority task.

As mentioned above, regular time should be set aside for getting Stories or Ideas to the backlog and contributing to the other machinery like Continuous retro. I’d suggest trying things like an hour a day, or picking a job off the Story development pipeline alternately with backlog items.

To the backlog!

Why another process?

Once someone has had an idea and put up a story, how do we get that to a state that can be turned into something tangible? Whose job is it?

This job is hugely important to most teams and organisations, and it answers the questions that we always ask:

what makes it worthy of doing?
what does it involve?
is it even feasible?
how important is it compared to other things?
how long might it take?

Ask any of these questions up front to a team member and they’ll say “um… I’ll get back to you,” because it involves actual work. They may just say “a couplaweeks” because they’re sick of being dumped with working out what the hell you want done.

This work is often forgotten, and it has to involve what is called the Product Owner in scrum, they have to work at it, and be guided. This bit is iterative and “owners” often want it over and done with (just…. do it!) so they’ll schedule a meeting to “get it done.” What they don’t realise is; discovery is a journey, and we’ll need to ask more questions, even after we’ve started work.

Whose job is this anyway?

In larger organisations “Product Owner” is a misunderstood term, because “I don’t own it”, or “this part of the app is another departments responsibility”. So what can we use instead? Maybe it’s not one person?

We like one person to be a product owner so we don’t have to deal with lots of people and have meetings and what not (just like the manager who just wants it done). But we need to deal with people because… that’s the job, that’s every job. So lets see, we have:

The person who had the problem
The person who has an idea to “solve” the problem inside your product’s context (The Story)
The person who has responsibility for the product, and the vision of what it is and is not. (ie. the owner)
The project manager if there is one.
Contributors.

In the above each “person” could be multiple people or a community, especially in open source projects. Contributors are very important and shouldn’t be forgotten, they provide vital feedback that should not be ignored. All these people are stakeholders. (The person who had the problem and the Contributors are often referred to as the Users, I’m avoiding this terminology because Users have multiple roles)

This is a process of communication and education. We’ve had Business Analysts (BAs) whose job it is to interpret business requirements and document into something like Enterprise Architect, but inserting that person is an abstraction layer, “Business” becomes a noun, and they are not exposed to the realities of the “Devs”. “Business” lose touch with the product and continually try to get new graphs out of people to understand where we’re up to - i.e. they don’t know what we’re doing, and why something doesn’t work. They don’t understand their own product. However, BAs document requirements which is really good.

So, Whose job is this?

Everyone. The person who has responsibility for the product (vision) should drive it in conjunction with the developers.

How?

What we want is the most direct connection between the stakeholders and developers. It’d be great if it could be asynchronous to allow for remote workers, and inspiration. We definitely need documentation, and that should be directly from the people who understand what needs to be communicated.

A Wiki or Task could be used to drive this process. Document the story as simply as possible, have a question and answer section, a conclusion or solution that links to the story, a breakdown of steps to implement, estimates and a vote. Information about what “done” looks like and who will review the story when done.

The states of this process are:

Story development → task analysis → estimation → priority → backlog

Story development

Story development is where we ask questions about the problem to understand the proposed solution. We ask the owner if this fits the vision and provide feedback. Apply You Ain’t Gunna Need it liberally here and come up with the minimum viable solution to put back in front of the Contributors. You may need to split this into multiple stories and iterate.

This is Agile. People often don’t know what the solution should look like. Get something out to them in a working form ASAP and get them to try it, then improve the solution. This feedback tells you what is important. This approach gives you the best solution for the money spent at any stage in a project. It does not guarantee that the solution will be the right one, Contributors might see the solution and change their minds, but you’ve spent the least possible to get there.

Task analysis

Task analysis is where you break the story down into tasks required to get it done technically. These are bite sized bits of work one person can get done in under a week. Tasks may be done in parallel.

Estimation

Estimation is where all developers, reading the documentation, give a gut feel for how long in days it would take to do each task - we take the average as the estimate. We do not question the estimate or force developers to rethink these based on business time lines. This is an estimate, which is a guess, which is from experience. We will see how good the estimate is.

Priority

Once we have the estimates it is the owners responsibly to co-ordinate a priority for the story. They could take a vote of stakeholders perhaps, but what they say goes.

Once all that is done, it goes on the backlog for development, where developers can pick (by default the highest priority) tasks to do.

Do we need a Project Manager?

Do you need a Project manager? That depends on the constraints.

For arguments sake.^[1]

Let’s call a Project something that has a set deadline, set of things (e.g. features) that must be done, and a set budget.
Let’s call a Product something that has a set budget or deadline and a purpose (problem definition and vision). A product may be further developed.

Both a Project and Product have a budget, but a project needs to deliver a minimum set of requirements within it’s budget and timeframe.

A Project needs a Project Manager. A product does not.

A classical Project Manager manages resources to provide a fixed outcome that fails if it isn’t achieved within the timeframe and budget. Timeframe, features and budget are fixed. Projects fail by this definition a lot. Projects often fail to provide a solution to a problem since the features tend to be fixed so that they can be project managed. Change anything and "all bets are off!"

A Product can have a Project Manager, especially if you have multiple teams. Their job is to co-ordinate people if you are badly structured and silo areas of concern. They’re basically a dependency manager, where a Gantt Chart could be useful.

People often say just throw more money at it to get a job done by a certain time. That rarely works due to the exponential increase in overheads like communication, management, learning curves, and team building. If a project is already running “late” it’ll run later if you double the size of the team now.

1. A project can obviously be anything people do, we just need a taxonomy for our explanation.

nerdErg

Open source

Contact Us

Regex - quick guide

What is Regex

Regex Components

Anchors

Quantifiers

Grouping

Sets of Characters

Shorthand Character Classes

SKRAM

Fast Agile with less ceremony

Essence of SKRAM

As open as possible:

Asynchronous processes:

Promote good documentation first:

Promote automated tests and test-driven work:

Daily Stand-up:

Continuous retro (it’s just story discovery):

Sliding sprint window:

Estimate gut feel:

Kanban backlog but:

Dev workflow

Continuous Cycle

To the backlog!

Why another process?

Whose job is this anyway?

So, Whose job is this?

How?

Story development

Task analysis

Estimation

Priority

Do we need a Project Manager?

go to Blog archives...