Start Practicalli Software Engineering book

[practicalli-johnny]

brain dump of ideas for book covering concepts and practical techniques for effective software development

Intro

Software engineering is the construction and maintenance of systems within a large number of constraints (technical, time, financial and social)

Topics

• lean practices and principles
• Agile Manifesto and associated practices
• Decision making practices
• People management (people ware)
  • hiring, on-boarding, building teams, scaling teams, developing practices, building consensus, career progression, agency, coaching, continuous improvement
• Communication (underpinning everything)

software engineering is

• An engineering discipline
• A science
• A craft
• A creative process
• Problem solving
• Negotiating constraints and managing trade-offs
• A people centric activity
• A social activity
  • open source projects
• A range of communication activities (communication between human and computer, between humans working hand in hand, between humans with a loose connection, between humans with little experiences in common, between humans who will never communicate directly)
• advocacy and audience engagement
• maintenance - Keeping systems working
• managing expectations
• managing constraints

Misconceptions of agile

Agile is not a prescriptive process

Agile is foremost about the principles and whether they are reflected in everything you do.

If you believe agile is a process, forget everything you know and go read the agile manifesto.

Agile is a set of principles and has practices that could be applied to support those principles.

There are many ways of forming a set of practices that could be applied when carrying out valuable work.

When thinking about process, it is very easy to forget the principles.

Agile practices should be applied when they apply value to the business of developing software. This requires input from a range of stakeholders

• business focused
• user focused
• technical architecture / design / organizational
• team using those practices
• individuals using those practices

The curse of a packaged process

Scrum is often seen as a prescriptive agile process that requires a range of practices.

None of the roles or practices that Scrum assembles are essential to getting benefit from Scrum, although there is a focus on practices that work together.

I dont know if this fits into agile

If you ask yourself this question, then you are thinking about a prescriptive process

Agile is not a prescriptive process.

So, does this fit into agile?

Ask instead which of the agile principles it supports.

When a practice, tool or technique under consideration provides a valuable way to demonstrate support for an agile principle, then that practice tool or technique should be defined as useful appraoch within the context that supports one or more agile principles.

Just because some technique is part of a prescriptive agile process, does not guarantee it is a useful technique for your specific context. In fact it could be very counter productive.

Lean software development

• pull systems
• working to the constraints
• Alleviating constraints
• Kaizen - continuous improvement

open source

• being a project maintainer
• Engaging with the community
• Encouraging adoption and contributions (identify the constraints that prevent others contributing)
• Adding other maintainers
• When to open source a project
• Licensing a project - choosing the right license

External research

• https://twitter.com/girba/status/1352734434613727232?t=Po-WJraLTZqfRg95EPNmWw&s=19
• https://twitter.com/girba/status/1495182102018547719?t=lmUy0ARcAk9YsRvs_Gz0_w&s=19

[practicalli-johnny]

Add specific tasks and guides to the https://practical.li/engineering-playbook/ and review if there is still enough content ideas to create its own book.

Possibly evolve this into a book like 'The Goal'