Design & Architecture
Greenfield and/or Brownfield Software keeps Evolving and is Never Done, (co)evolution are always fascinating from learning perspective, like all over night successes, 10+ years and 100s of man years of work!
- Accepting slow migrations
- Accepting legacy subsystems
"Wandering is an essential counter-balance to efficiency. You need to employ both. The outsized discoveries – the “non-linear” ones – are highly likely to require wandering." --Letter to Amazon Shareholders
You have no idea what you don’t know. A lot of the people who wrote these applications are gone. So far, your organization has gotten lucky—the apps have been running pretty well, they don’t go down very often. But because they haven’t been touched over the last 10 or 15 years, you have to reverse engineer them to understand how they work. -- https://allma.io/blog/6-key-lessons-kelsey-hightowers-kubernetes-migration-workflow
First a bit back in time retrospective and forward Amplify building tools or using best tools, a sustainable model with universal core principle of Going far, Together with product, community and engineering. A lot of connecting dots from a following on Twitterverse Thank You 🙏 ,eternally grateful.
The story of computing is the story of humanity. This is a story of ambition, invention, creativity, vision, avarice, and serendipity, all powered by a refusal to accept the limits of our bodies and our minds. -- https://computingthehumanexperience.com/about/
Steve Jobs' 2005 Stanford Commencement Address
When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960s, before personal computers and desktop publishing, so it was all made with typewriters, scissors and Polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: It was idealistic, and overflowing with neat tools and great notions.
Stewart and his team put out several issues of the Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.
- John Markoff | Floating Upstream: The Many Lives of Stewart Brand
- Whole Earth 50th Anniversary Celebration
- Whole Earth Catalog’s Long Legacy over 50 years
- Stewart Brand | Talks at Google
- Encyclopedia
We design in the open with a transparent and participatory process. We collaborate within the Wikimedia Foundation and with the global community of contributors. We create well-designed solutions, together.
-- https://design.wikimedia.org/ -- https://www.mediawiki.org/wiki/Wikimedia_Architecture_Team
- [Products & Business]
'You' in 'YouTube'
"YouTube confers agency at every level—kids can become world class musicians just by watching other kids...everybody can figure out how to repair something. YouTube gets people feeling like they can weigh in on anything—it's just fantastic." —Stewart Brand
- Open Core
Open source inspires Thus far, the Backstage Upgrade Helper has gotten a lot of good feedback from the community and we’re sure to see awesome contributions in the future. But all the credit behind this idea goes to the React Native community.
With React Native’s open source contributions, we were able to quickly solve a tough problem for the entire Backstage community. Not only did React Native’s project save us time creating a new product, but it has also saved our adopters time upgrading Backstage.
This is why we love working in open source. The hard work done for one community has the power to influence and inspire another community. We hope Backstage can do the same and pay it forward to other open source projects.
-- https://backstage.io/blog/2022/03/04/backstage-upgrade-helper#open-source-inspires
Fun fact: @dagger_io is developed entirely in the open. Yes it's open-source, but beyond that: the maintainers (employed by Dagger or not) discuss everything in open channels: https://discord.gg/dagger-io. Even live meetings, to discuss priorities or debate design, are open by default
-- https://twitter.com/solomonstre/status/1509967925972660227
+
The way that change actually happens is action or behaviour first, values and attitudes second, not the only way around. Merrelyn Emery puts it succinctly: “And no matter how many times you sing the song, you need more than love.”
Equally important, this type of change is not something that should be done only in parts of the organisation; this must be complete structural change, utilising the second most effective leverage point in Donella Meadows list of places to intervene in a system. “The mindset or paradigm out of which the system — its goals, structure, rules, delays, parameters — arises.”
Open Sociotechnical Systems Design -> https://www.infoq.com/articles/open-sociotechnical-systems-design/
+ technology & agency collaborate for a better world "real-time authoritative journalism" & Volunteer editors building out the page
- exponential dangers of identity, spam, fraud surrounding anonymous online/real world linked activities with notions "growth hacking", Blitzscaling (AKA going alone and less Together), less considerations for societal implications enabled by vulnerabilities in account management, security & bots since good old early (Yahoo!, MSN, AOL, ...) versions of "social" Mail/IM clients across & content types Text -> Photo -> Video (AKA Webcam). The challenge is that the communities were relatively smaller compared to massive global scale media and (dis)information (lies) operating across many platforms.
+
Musings on user agency in computing and the future of programming tools
It's overwhelming work going on in open source world, more agency tools like search including software design will help (right now we have problem of more code and less real world software design).
+
Open-source software has made it easier for software developers to study and learn programming by looking at real-world working software. But what about software design? Building architects (not software) study thousands of buildings in their training and career. Software developers, in contrast, only study a handful of other large software designs. This means we repeat mistakes that we would have been able to avoid, should we be able to learn from others.
-- https://notes.ceilfors.com/Open_software_design.html -- https://upmo.com/dev/
From 2021 Organizational Dynamics Masterclass
Polarity Management: Tactical/Strategic, Centralization/Decentralization
Ruth Malan: Here's my understanding: In a polarity map, we recognize that there are poles, and over-emphasis could get us putting too much effort in one or other pole -- at which point the impetus to move away from the downsides of the pole would be strong. So we're seeking to get more "both and" which takes taking actions, and watching for the signals of a dip into too much of a pole (and hence too much of its downsides). The polarities are unavoidable -- for example, we can't avoid there being some architecture decisions made in the teams without coordinating across teams. We want high autonomy in teams, so they're making a lot of decisions. And some of these will turn out to be architectural(ly significant). At the same time as wanting teams to have degrees of independence, we want architecturally significant decisions to be made from a system perspective. So what can we do, to make more of that happen, and happen in time? (Whereas a dichotomy would say: pick one, you can't have both. If you have team autonomy you can't have architects (role or hat); if you have more team autonomy, you have less architecture (at least, less architecture (as intentional design; there will still be "accidental" architecture, etc.); etc. There is no notion that by taking actions, you could get more autonomy (where it matters) while still having (just enough) architecture (where it matters). Etc.)
Dana Bredemeyer: There are some interesting issues to tease apart here. Do you have a couple hours? 🙂 I find it helpful to distinguish between the level of an architecture and the level (granularity and location) of a decision. The level of the architecture can also be called it's scope or system view. Is the scope of a particular architecture the car, or the drive train (part of car), or the engine (part of drive train)? Let's say we're architecting the drive train. Drive train architectural decisions that do not impact car level desired outcomes are owned / made by the drive train team. If they DO affect car-level desired outcomes, then those decisions are owned / made by the car architecture team. Generally these are different teams, and the architectures are best viewed as different architectures. There's a car architecture, a drive train architecture, and an engine architecture. The DESIRED OUTCOMES cascade from broader to narrower scopes and back again. If the system being designed is a coherent system (such as a car) and all teams understand and are committed to overall car-level desired outcomes, then decisions at narrower scope must not compromise broader scope desired outcomes, but the need to achieve broader scope outcomes CAN drive very detailed decisions in narrower scope. All this gets more complicated when, for instance, the engine is made by a third party who also sells their engine for use in other cars, which have different sets of car-level desired outcome. Sheesh. We're just getting going here and already we can clearly see the highly-connected nature of organization strategy, product strategy, and organizational design. Architecture is challenging. I think Ackoff's short video also does a good job of addressing this. https://www.youtube.com/watch?v=OqEeIG8aPPk
Thread: https://twitter.com/ruthmalan/status/1500946070586671104
Three sisters and reciprocity: each is receiving and giving something back; more resilient together.
This is a great visualization of the various control and network structures. The lines between centralized, decentralized, and distributed systems aren't as clean as people think.
While the underlying system can be decentralized the control structure may not be. -- https://twitter.com/kelseyhightower/status/1487876237917777927
Why do suspension bridges have stranded cables not solid rods? The major reason is that solid rods would fail suddenly and catastrophically, whereas stranded cables fail slowly and make alarming noises while they do. We build software systems out of solid rods; they fail abruptly and completely.
(VS Code Day Keynote with Erich Gamma, "Gang of Four")
Press "." while on any GitHub repo to open it in a VS Code editor in the browser. Developer Tools Notebook, Studio & IDE (co)evolving like ⬆️VS Code 10 years journey, JetBrains with Space / Gateway / Fleet to reimagined Repl.it is not an IDE, Retool - The future of internal tools, collaborative code editor, AI pair programmer, GitHub Next investigates the future of software development, a new kind of programming environment, A story of tools and the future of work and increasing sprawl of developer experience Toolchain.
Baker, recipes allows product owners, architects and developers to talk the same language -- https://github.com/ing-bank/baker
Once more: we are not modeling reality, but the way information about reality is processed, by people. — Bill Kent
https://buttondown.email/hillelwayne/archive/why-you-should-read-data-and-reality/
Product Development as a collaborative discipline between all parties with one common goal: solve the real problem of our customer. It can be done, it is no voodoo, no magic.
'It is not the domain experts knowledge that goes in production, it is the assumption of the developers that goes into production' This famous quote from Alberto Brandolini is unfortunately true but it also points to the right direction: we need to bring the domain knowledge into our software. I would be happy to show you how and to have a discussion about it From The Problem To Software - a Walkthrough with Krisztina Hirth
There's a saying that writing software is more like tending a garden than constructing a building -- things constantly change.
But the more I learn about how buildings evolve, I think this process is actually a perfect analogy for designing software!
Thread: https://twitter.com/geoffreylitt/status/1272542423001022467
product takes a village design, design research, development (across different areas), data expertise, marketing, product management, (and many more) ...the idea that product = product management is very limiting.
In my last product release we designed stickers to thank the village of people that helped make the release happen. In our list of people to send stickers, there were 85+ people. https://twitter.com/eileendoodles/status/1488617248529035272
Programming as architecture, design and urban planning / PDF
once you empower people, giving them an environment in which to succeed, and recognise their successes, they will rapidly, and as a collective, start thinking about things which haven’t even crossed your mind. That’s the real benefit of this kind of approach: access to the collective intelligence of the many, over reliance on the much more restricted intelligence of the few.
Open-source software has made it easier for software developers to study and learn programming by looking at real-world working software. But what about software design? Building architects (not software) study thousands of buildings in their training and career. Software developers, in contrast, only study a handful of other large software designs. This means we repeat mistakes that we would have been able to avoid, should we be able to learn from others.
Open software design is the idea that software design must be available for public use. It's the idea that we should Work with the garage door up. The main audience of the design is developers who built the software, and not external people. The contents are living artefacts, they naturally evolve as the software evolve. In the world where the majority of large real-world programs are closed-source, opening up our software design documentation is the least we can do to contribute back to the community.
think a lot of it we benefit a ton from the open source community and just all the learnings there that are laid bare in the open, all the mistakes, all the success, all the problems, it's a very slow moving process, usually open source, but it's very deliberate. And you get to see because of the the pace, you get to see what it takes to really build something meaningful, learned most most of everything I learned about hacking and programming and engineering has been due to open source and the the generosity that people have given to give up their time, sacrifice their time without any expectation in return other than being a part of something much larger than themselves. Yeah, I think it's great. -- Engineering at scale
"In most open-source projects, efforts to attract and bring in new contributors are clearly aimed at developers, but this means they miss the opportunity to attract other types of profiles that could be easier to bring in and could also help the progress and long-term sustainability of the project," - Software for all: how do open-source communities work?
Humans are hard-wired for collaboration, and new technologies of communication act as a super-amplifier of our natural collaborative mindset. This new collaborative society might be characterized as a series of services and startups that enable peer-to-peer exchanges and interactions though technology. Some believe that the economic aspects of the new collaboration have the potential to make society more equitable; others see collaborative communities based on sharing as a cover for social injustice and user exploitation. -- Collaborative Society.
Open collaboration is "any system of innovation or production that relies on goal-oriented yet loosely coordinated participants who interact to create a product (or service) of economic value, which they make available to contributors and noncontributors alike." It is prominently observed in open source software, but can also be found in many other instances, such as in Internet forums, mailing lists and online communities. Open collaboration is also thought to be the operating principle underlining a gamut of diverse ventures, including bitcoin, TEDx, and Wikipedia. -- https://en.wikipedia.org/wiki/Open_collaboration
Having a community that you can learn from, … I think it was the reason I got into software engineering, the reason I was able to get into it so quickly and so easily. There’s so many different ways you can learn. -Kate (chemical) -- The Crossover Project
Open design welcomes the free exchange of ideas, knowledge, processes, and tools. It empowers by lifting barriers to innovation. It opens the door to scaling design projects by distributing adaptable resources.
Design, Architecture, Frontend/Backend, DevOps/SRE, Quality, ...
- In defense of simple architectures
- Technical Leadership Masterclass
- AWS re:Invent 2021 - The architect elevator: Connecting IT and the boardroom
- “Crossovers”: people who used to work as traditional engineers and now work as software developers
- Architecture for Flow w/ Wardley Mapping, Domain-Driven Design, and Team Topologies
- Best vs. Rest Explained
Development & Storytelling:
- Stories > Code
- documentaries exploring tech culture, influential technologies and untold developer stories from around the world. Check out stories around open source, careers and all the other cool stuff developers are doing over at cult, our media platform
- Developer Relations
- Filling the Stack: Five Things That Helped Me Transition From Frontend to Backend Development
- https://github.com/salaboy/opensource