Topics inbox

[stanislaw]

Day-to-day work

• Fast feedback. Fast tests, invest into faster tools and processes.
• If a process is done once or rarely, it will likely be slow and full of mistakes or issues.
  • When it is not worth to automate.
  • Override automation.
• Making decisions in hard situations. Saying NO or YES.
• When making decisions, loop in experts. Over-including is better than under-including.
• Spread knowledge and best practice.
• Unify and share workflows with the team.
• Praise work.
• Upstream-downstream.
• Maintain curiosity, look around (e.g., GitHub).
• Context to fit enough/all aspects of a problem -> Mindmaps.
• Checklists.
• Good enough.
• Logs.
• Naming. Folders, files, documents, projects, tools, naming conventions.
  • Bad naming contributes to periphery in a negative way.
  • Bad naming can cause mistakes and project delays when people have to fix them.
  • Inconsistent naming convention is a constant attention sink.
• Invest into good tools.

Cognitive

• Effective learning is a result of computation. Over-internalizing that leads to biases. Learning how to do a pattern and then how to undo it. Source of truth example.
• Order (wires and clothes)

Design

• The systems are not based on perfect design.
• Centralized vs federated.
  • A single data storage for all apps, or all apps have their own data storage.
  • Monoliths vs microservices.
• Before something can scale, it must exist.
• Bad design -> No longer adequate

Coding

• Git commit names: Context: Title.

Distribution

-

Maintenance

• Cloning or re-implementing an existing solution is easier than creating a new one.
• Maintenance Trade-offs
• Newcomers vs aftercomers (maintenance programmers).

Documentation

• Software Architecture Document, Design File, Design Document. Whether a large company or a startup. Must exist.
• Software User Manual Document.
• Documentation is a garden.
• Hierarchy, composition, zooming helps in chunking information
• Redundancy in text: strengthens the common understanding / helps finding errors. This is an exception to the Single Source of Truth principle.

Diagrams

• I/O model
• Control/Feedback diagram
• Static diagram

Communication

–

Management

• Good, when no one understands the timelines and how much the work will actually take.
• Using engineers. Engineer – personal pride, intuition of everything possible.
• Estimates and intuition. Developers just don't know when they estimate but they may not tell.
• Research teams vs execution teams.
• Managers are your friends.
• Open positions are not emerging by themselves. Driven by some pain.
• Workforce: Transformation of unknown to boring

Systems

• Top-down systems engineering. Single entry point to every topic as anchor. One page per topic.

Top down system engineering is critical for engineering safety into complex systems (MIT ESW)

• Systems Engineering as manipulating a graph of interdependent artifacts.
• Traceability
• Safety cannot be analyzed without requirements.
• Functional Decomposition that drives the Work Breakdown Structure and the master schedule planning.
• Systems engineering activity consists of computation tasks. SysEngineer acts like IO device.

Organizations

• In the beginning there was cash.
• Too many lessons learned paralysis.
  • The development still happens because something has to be built.
  • New companies cannot implement all lessons learned at the same time.
• Spring - Making mistakes. Winter - Death from too many lessons learned. Rigid processes as a reaction of failure.
• Struggle for survival
• Inherently messy.