171–180 of 202 posts
Earlier quoted context omitted.
Um, no. The real world is not that simple. It would be nice if it were. Or perhaps your statement is correct, but in the real world components are never sufficiently separate. So, while your statement may be correct by definition, it is not useful.
You are misreading my words.
There is an entire poster of funny 'laws of computing' that was created in 1980 by Kenneth Grooms. It's pretty amazing how many of these are completely relevant 40 years later... It's hard to find the original piece of art, but my uncle had this hanging in his office for a long time, and now it's hanging in mine. I transcribed it in a gist so I had access to them for copy/paste. https://gist.github.com/sorahn/905f67a…
Postel's law, "be conservative in what you send, be liberal in what you accept"is definitely not "a uniter"! https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...
Hyrum's law is highly relevant to anyone who makes software libraries. "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." I.e. any internal implementation details that leak as behavior of the API become part of the API. Cf. Microsoft's famous "bug for bug" API compatibility through versions of Win…
They might become part of the API in a superficial sense, but if you broadcast clearly that undocumented behaviors are subject to change, then users can decide if they want to accept that risk and won’t have a valid complaint if they want the not-covered-by-the-contractual-API preserved or become surprised by a change.
Don't forget Atwood's law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."
Or Greenspun's Tenth Rule of Programming : Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp.
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
* All software has bugs, no software is inefficient
* A programmer's work is never done
Hyrum's law is highly relevant to anyone who makes software libraries. "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." I.e. any internal implementation details that leak as behavior of the API become part of the API. Cf. Microsoft's famous "bug for bug" API compatibility through versions of Win…
Earlier quoted context omitted.
You are misreading my words.
Perhaps so. Would you care to explain? Your statement here doesn't give me much to go on.
> in the real world components are never sufficiently separate
But the separation of components is not an issue of "real world", it is a function of design and implementation. It is absolutely to the developers how independently the components will be implemented; if there is no way to test them in isolation, then they are not really separate components.
Take this website, and your browser, as an example. They are obviously connected, as you're using the latter to access the former, but they are completely independent: you can access other pages with the browser, and you can use other methods (other browsers, or curl, or Postman etc) to access this page. Each can be tested separately, and even when they are used in conjunction they don't directly depend on each other, but rather on a set of standards (HTTP, HTML, CSS etc) understood by both.
A programmer can accurately estimate the schedule for only the repeated and the redundant. Yet,
A programmer's job is to automate the repeated and the redundant. Thus,
A programmer delivering to an estimated or predictable schedule is...
Not doing their job (or is redundant).
Earlier quoted context omitted.
> “Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams.” This actually sounds very dysfunctional, but with the type of positive PR spin that product / executive management wants, basically anyone who believes “cross-functional” is anything more than a buzzword. Would love to know what…
Aside from the working overtime part, what sounds dysfunctional?
This part is often much worse than the overtime part, because it means you’re expected to sublimate your personal career goals in favor of whatever arbitrary thing needs done for the sake of the cross-functional unit.
When I hear someone describe communication between cross-functional team members as “good” or “effective,” then I know it’s a big lie, and most probably it’s a disaster of overcommunication where product managers or non-tech leadership have a stranglehold on decision making when really engineering should be autonomous in these cases exactly according to independent specialization.