Developing software infrastructure that doesn’t add business differentiation as open-source is faster, more cost-efficient, and leads to better results than keeping it proprietary. It also allows more focus on business-critical software.
The physical world that we live in defines our paradigms, how we think about business and trading goods. If one owns a material item, let’s say a bagel, and gives it to somebody else, one doesn’t have it anymore. …
Part 1 of this blog series made large organizations agile and efficient by developing business capabilities through empowered, vertically integrated teams and tech stacks of manageable size. Part 2 uses inner-source to boost collaboration and the collective IQ of the organization. In part 3 here, we use a mono-repository to make sharing and collaboration the economical and rational choice, enable long-term health of the company’s codebase, and improve the company culture along the way.
what is a monorepo
Many organizations have multiple code repositories, each one containing one codebase. We call this a multi-repository or short multirepo layout. But one can store more than one logical codebase in a code repository. Thinking this idea all the way to the end means the organization has just a single code repository (a mono-repository or monorepo) that contains all the code, tests, test harnesses, documentation, DevOps scripting, and infrastructure definitions — everything minus the business secrets. Some monorepos also contain the source code of open-source dependencies as well as all other tools you need to compile, test, and run your applications. …
In part 1 of this blog series, we made large organizations agile and efficient by developing business capabilities through vertically integrated teams and tech stacks of manageable size. Doing so reduces dependency gridlock, meeting time, and increases the agility and efficiency of the business. A challenge with this setup is that so much independence can compartmentalize the organization. Inner-source, another key ingredient of modern technology-driven organizations, takes collaboration, efficiency, as well as the collective IQ of your organization to unprecedented levels.
what is inner-source
Conventional corporate culture optimizes for control and predictability. Its tendency for top-down decision making can produce insufficiently challenged decisions because of reluctance to express conflicting opinions, centralization, and problems scaling leadership. If incentives are misaligned, an organization can experience substantial amounts of internal friction and competition. Know-how to maintain existing systems is often poorly documented and not widely shared, causing hit-by-bus problems. …
TLDR: Often overlooked in discussions of micro-services are their positive effects on the human organization. Following Conway’s Law, micro-services are a modular, vertically integrated technical architecture matching a loosely coupled, vertically integrated human organization structure. Both together enable efficiency and agility in large organizations.
Micro-services are a radical, counter-intuitive, controversial, and at the same time enlightening topic. In my opinion, the debate around them focuses too much on technical aspects like code and DevOps complexity. Often overlooked is that micro-services increase the efficiency and agility of human organizations.
A common theme across all projects and companies I have worked with was that most of the challenges on technology projects come from the human part of the system and not the technology side. Company-wide dependency gridlock slows every initiative in a large organization down to molasses. Endless meetings take up most of the working hours and leave little room for actual work. …
As software developers, we are fortunate to have many useful best practices for productive and fun coding, like the SOLID principles, GRASP patterns, or STUPID anti-patterns. These principles are timeless and apply to many forms of coding, no matter which programming paradigm or language you use.
Here are a few more that I have found useful to keep the process of developing, maintaining, and evolving software over a long time simple and easy. They are aptly named the SIMPLE principles:
- Strong data types: model your data precise enough for your domain
- Immutability: limit mutability where possible
- Misuse-proof APIs: make it impossible to use your interfaces the wrong…
You can also read this story in Chinese on InfoQ.com or join the discussion on Hacker News.
summary
Go — a programming language designed for large-scale software development — provides a robust development experience and avoids many issues that existing programming languages have. These factors make it one of the most likely candidates to succeed Java as the dominating enterprise software platform in the future. Companies and open-source initiatives looking for a safe and forward-looking technology choice for creating large-scale cloud infrastructures in the coming decades are well advised to consider Go as their primary programming language. …
tl/dr
Like code bases, the policies and best practices making up a company are collaboratively developed and owned bodies of text. Github is an excellent platform to develop both with a large group of collaborators. The company I currently work at (Originate) uses GitHub as such an intranet platform. This enables an unprecedented level of collaboration, but more importantly empowerment and transparency for all employees.
GitHub is a collaboration platform
Over the past ten years, GitHub has evolved from (arguably) the best software development platform into one of the most productive general-purpose collaboration and community platforms that can develop all sorts of content, not just source code. …
I am thrilled to announce a preview release of Tertestrial, an open-source tool that makes running automated tests as part of developing software more natural and seamless.
why we need to run tests a lot
In TDD and BDD (test/behavior driven development) our tests don’t just specify and verify that code works, they drive the entire development workflow. Instead of writing code initially, we write tests first. Then we let the error messages from those failing tests tell us the next thing to do with our code base. We implement the smallest amount of code that makes that error go away (this is often just a few lines of code) and run the test again to verify that this actually worked. If there is a new error message, we make that one go away via another code change. If the test finally passes, we write more tests and start over. …
The Go programming language and tool stack have been designed to combine manual and automated software development in novel ways, paving the path for how software will be written in the 21st century:
Humans will be slow-rolling the creative parts while automated tools (cobots) take over the repetitive parts like upgrades, maintenance, and keeping it all working.
The Go makers have laid out their powerful vision for this in a post on the Go blog a few years ago. They also made a tool called gofix that updates existing Go code bases to new language features of the Go language. …
Implementing several different unrelated code changes at the same time in the same feature branch is like trying to have a conversation about several completely different topics at the same time with the same person, or other forms of multi-tasking. It’s never productive. We end up mixing up issues or forgetting to think about important edge cases of one topic because we are distracted with the other topics. We only have parts of our brain available to think about each topic. …
