5 ms·
> As an engineering manager, I cannot imagine assuming that people would read something. Engineers read code when they have to work on it. If naming and struct
by pmontra 4y ago
> As an engineering manager, I cannot imagine assuming that people would read something.
Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why.
Unfortunately it takes a lot of time to learn how to code in such a way that the author and coworkers can come to that piece of code six months from now and understand what it does.
A corollary is that everything should be automated or made impossible to do, because even looking at the company's wiki is something that most people prefer not to do.
Unfortunately it's difficult to know which automatic process is doing something, given that that something is a known unknown.
- pjmlp 4y agoNon functional requirements aren't code, good luck writing code that reflects them.
- tcfhgj 4y agoit's possible, e.g. you can time code easily
- pjmlp 4y agoOne case among thousand possibilities of what a NFR is all about.
- tcfhgj 4y agoJust wanted to show that requirements being not directly reflected in code doesn't mean that they can't be tested against; Further investigation certainly makes sense
- lifeisstillgood 4y agoI think that 999 of the thousand can be brought into the virtual realm - and that companies that do so will find their ability to measure and chnage the important non functional requirements will be an advantage. Just some ideas: - speed (obvious) - capacity (that's fairly obvious too) - reliability (MTBF, incident count) - The Google Speed vs stability metric - usability (starts out as a toughie but if you record users mouse / UI activity then it becomes measureable - and this is kind of the point - the more HCI is captured and available to the "virtual world" the more these problems are within reach. the more software eats, the more it can eat. - scalability : scaling up or down? Measureable
- pjmlp 4y agoI am really curious how-to express MTBF in e.g. C.
- kodah 4y ago> Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why. In early greenfield software, sure, but given the test of time this assumption will always fail. The reason is that each team that works on a given software has an operating context that's often undocumented. They use lingo and rhetoric that likely aligns to that and is illuminating now but when that lingo isn't as common it'll likely die off. The very idea that words of a contextual language will be exactly relevant in the future is a short-sight in its own. Writing a lot of docs has its own tradeoffs, but I do think it's worth pursuing principles of writing good notes. I'm oft fascinated by reading the comments on old code that remain durable.
- lanstin 4y agoAnd documenting the lingo, the concepts with which the software was designed is more important than some system diagram or call sequence charts or API stuff. (For the maintainers; API consumers obvi need something).