In the year 1930, John Maynard Keynes predicted that, by century's end, technology would have advanced sufficiently that countries like Great Britain or the United States would have achieved a 15-hour work week. There's every reason to believe he was right. In technological terms, we are quite capable of this. And yet it didn't happen. Instead, technology has been marshaled, if anything, to figure out ways to make us all work more. In order to achieve this, jobs have had to be created that are, effectively, pointless. Huge swathes of people, in Europe and North America in particular, spend their entire working lives performing tasks they secretly believe do not really need to be performed. The moral and spiritual damage that comes from this situation is profound. It is a scar across our collective soul. Yet virtually no one talks about it.

A lot of evidence suggests that in cases of this kind, employers will stubbornly trust their intuitions — and are badly mistaken to do so. Specific aptitude tests turn out to be highly predictive of performance in sales, and general intelligence tests are almost as good. Interviews are far less useful at telling you who will succeed.

It’s a situation many of us are familiar with: a large legacy, monolithic application, limited or no tests, slow & manual release process, low velocity, no confidence… A lot of refactoring is required but management keeps pushing for new features. Now what? We talked to Michiel Rook, a Java/PHP/Scala contractor and consultant about the challenges that walk hand in hand with continuous deployment.

Every line of code has some probability of having an undetected flaw that will be seen in production. Process can affect that probability, but it cannot make it zero. Large diffs contain many lines, and therefore have a high probability of breaking when given real data and real traffic.

This article outlines the scale of that codebase and details Google's custom-built monolithic source repository and the reasons the model was chosen. Google uses a homegrown version-control system to host one large codebase visible to, and used by, most of the software developers in the company. This centralized system is the foundation of many of Google's developer workflows. Here, we provide background on the systems and workflows that make feasible managing and working productively with such a large repository. We explain Google's "trunk-based development" strategy and the support systems that structure workflow and keep Google's codebase healthy, including software for static analysis, code cleanup, and streamlined code review. helps you manage and monitor your virtual machines, across different clouds, using any device that can access the web.

Debian should not have adopted it for at least a few more years; they’re supposed to be the slow, steady, and stable distro. Their quick move to systemd hurt a lot of feelings and caused half their team to leave for Devuan. That shouldn’t happen. If your team is that fiercely split on an issue, the correct response it to leave the status quo alone until cooler heads prevail. Debian lost a lot of their reputation for stability because of this.

StyrelseAkademien är en ideell förening som verkar för ett bättre styrelsearbete i svenska företag. Vår mission är att öka kunskapen om styrelsearbetets betydelse för lönsamhet och utvecklingskraft. Vi arbetar med utbildning, nätverk, rekrytering och opinionsbildning.

StyrelseAkademien Sverige har arton medlemsföreningar med över 6 000 individuella medlemmar. Vi utbildar ca 2 000 personer om året i styrelse- och ägarfrågor.

ADKAR is a research-based, individual change model that represents the five milestones an individual must achieve in order to change successfully. ADKAR creates a powerful internal language for change and gives leaders a framework for helping people embrace and adopt changes.

The Collective Code Construction Contract (C4) is an evolution of the Fork + Pull Model, aimed at providing an optimal collaboration model for free software projects. This is revision 1 of the C4 specification.

1–10 (66)   Next >   Last >|