Topics inbox

[stanislaw]

Day-to-day work

• Ubuntu 22.04 on QEMU/KVM
• Mechanical moves and behavioral changes.
• Staged construction of documents...
• Organize information into manageable areas.
• Focus on critical points.
• Integrate into existing team's workflow. Do not overload terms even if you know better.
• Analogy for requirements work: Junior -> L3, Senior -> L2, Staff -> L1.
• Don't cut the roots. (Don't forget about the roots (cFS how long it took))
• There can be multiple solutions to a problem. Solutions as permutations. The best is the one that makes sense to most of the agents.
• Do more with less.
• Use Python or other scripting to fill the gaps in your domain model.
• Sometimes a well-written script will do much better than an open source library with many stars.
• Accepting mess.
• Workflow -- workflow. Don't stop the flow. Resolving bottlenecks.
• [Philosophy of Software Design] Interface is a cost
• [Philosophy of Software Design] No point in extracting meaningless subfunctions. Creates bad abstraction.
• Change the game.
• Diagrams support mental work. SysML and other methods can enable or can prevent mental work, depending on experience and task. Extend or complement: The Limits and Choices of Models and Diagrams.
• Take a full ownership of complex and controversial topics or find reliable people and delegate the ownership to them.
• Iterative code review — more trivial things hiding more serious thing. Clearing layers after layers.
• Refactoring is like tidying up one's mind.
• Perfect world - Don't know how to test.
• Hacks/workarounds, e.g., zero-terminated strings, null pointers.
• Sense for irregularities. Order ~ control.
• Danger of framework - Over-constraining the implementation.
• Failed code review: copying an object.
• Copy-and-paste mistakes. Templates.
  • Company names, product names, technology names.
• 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.
• Upstream-downstream. Connect with It may be part of a chain where upstream or downstream effects matter..
• Context to fit enough/all aspects of a problem -> Mindmaps.
• 📌 Checklists.
• Good enough.
• Logs.
• 📌 Invest into good tools.
• Every task - shortest feedback possible.
• Synthesis of two: Plant the task and Superset of Conflicting interests — Usually it is quick and easy to do the work when the task is clear. If the task is not clear, there is most probably a real underlying issue. Ways out of conflicts: changing the game, getting new information, asking for feedback.

Customer-supplier

• Chicken-and-egg when integrating HW/SW interfaces.

Communication

-

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.
• Workforce: Transformation of unknown to boring. Complexity barrier after which it becomes boring.
• Developer is like compute operating on stack.
• Order (wires and clothes)

Design

• A good property of architecture is how well it helps to isolate domains.
• 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
• Partitioning - Helps to split content in one's mind. No partitioning - Everything mixed. Wrong partitioning - Wrong weights hanging on when reasoning about things.

Coding

• Portability of mental work.
• Mutating the original vs mutating a copy.
• Deep call stacks.
• Code reviewer is most always right.

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 User Manual Document.
• 📌 Documentation is a collection of notes promoted to formal pages. Immediate staging of notes to documents.
• 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

• Working out project milestones. Base on prior knowledge, standards, common sense. Key events throughout the project.
• 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.
• Estimates. Those how know how to implement something overestimate and the other way round.
• Research teams vs execution teams.
• Managers are your friends.
• Open positions are not emerging by themselves. Driven by some pain.

Meetings

-

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)

• Consolidate information.
• Systems Engineering as manipulating a graph of interdependent artifacts.
• 📌 Traceability. Relaxed naming traceability.
• 📌 Safety cannot be analyzed without requirements.
• Systems engineering activity consists of computation tasks. SysEngineer acts like IO device.

Safety

-

Testing

• Testing to functional decomposition.

Standards

-

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. Partially messy, partially perfect.

Conceptual

• Signature of intent.
• Feature matrix and integration tests. How to organize this in open source projects?
• Master schedule modeling.
• Tooling / methodology / culture.
• Use cases and functional chains.

Random

• Considerate - Water boiler. Being considerate. Partially addressed by Leave things better.