Start Practicalli Software Engineering book

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

practicalli / software-engineering