Topics inbox

[stanislaw]

Day-to-day work

• When I finish this chunk of work, I can then get to finish the rest 😄

• Cognitive:

  • Make it stick. Not just recognizing but reproducing. Diagram.

• Fluent/clear speaking without bursts in volume or rhythm. Colloquial speech.

• Talking over each other.

• Working with customer:

  • Avoid ambiguity.

• Us vs Them. Avoid. Use Names, avoid confrontation.

• Focus on Human/People

• Don't block the flow of meeting.

• Feedback to content vs feedback to style and structure.

• Lead and follow

• Estimates: 2.5 vs Pi

• Show, don't tell.

• Interrupting people, don't interrupt

• But the fact is everyone is busy with their own work.

  • everyone is in the process of doing something else
  • if you see something that looks like you are doing, that's very like someone
    was doing something else but similar

• Multiplicity harms the cognitive window.

• Star-based dependency graph is better than

• User friendly is superior than expert and sophisticated in the long term

  • ~Craft vs automation

• Clean code that does not work (see existing Code that Works)

• Lifecycle vs implementation

  • control code that changes state one level down, not on the same level?

• Principle of least surprise.

• Bugs are not OK.

• Nancy Leveson: "Responsibilities should be assigned" — this directly parallels the idea of making things very explicit in code: explicit safe mode management, error handling. In short, things that are not clearly assigned in code start to get lost and overlap.

• Too much! Interfaces that are too simple do not engage the operators’ thinking at all, which can negatively affect their performance later in critical situations.

• No matter what your argument is, someone will always come up with the counter argument for a particular example, missing the general point. https://news.ycombinator.com/item?id=15716543 (2017.11.19)

• Ubuntu 22.04 on QEMU/KVM

• The test procedure development process is a software development effort in itself. Usually about 1/3 to 1/2 the development staff (from https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20150019915.pdf)

• Safe architectures should not have single points of failure

• Too many layers might be confusing for people.

• Entry point into a file, a class, a package, etc. Finding key points of control hierarchy.

• 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, twisting their arms. 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.
• The limitations of your management are your subordinates limitations.
• 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, testing to use cases.

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.