I now favor code that has a lot of independent modules that can have hacky inner code but that must have clear, explicit and preferably simple interfaces. The project's manager role is to design these interfaces and has the last work on their implementation.
This is a bit the Unix way. Every module has to do one thing (and optionally do it well). This allows veteran programmers who know all the subtleties of the programming language to collaborate with rookie programmers who may write okay-ish modules that we may have to rewrite later but that work well enough.
It also allows programmers, these very territorial beasts, to have their own little realms they control and where they are acknowledged. It helps non-tech managers understand who has to be assigned on different issues and evolutions.
Every place that had a great team did it this way.
As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component/module. The latter is great, the former is a failure of the team's leadership. You can still get pride of having built something even if you're building it for the team and, through code review, the team is accepting ownership. But individual ownership of key pieces of code has been responsible for most of the top-10 shit storms I've seen in my career and I'm never letting it happen on a team I manage ever again.
But, absolutely, a lack of peer review, authentic feedback, and general teamwork causes all sorts of issues in so many ways.
Small nitpick: I assume to wanted to say this keeps your bus factor up.
One of the important function of the project manager is also to communicate clearly with upper management about what the team is and can do. We were working on a product that was not deployed yet and our priority was to release a functioning version ASAP, so redundancy was irrelevant. We had n features to develop, assigned to various developer. When one developer is on holiday, their features did not advance. We worked around it thanks to our modular architecture.
It meant that sometimes, <urgent but usually irrelevant feature> was impossible to code before <meeting with potential client next week>. I scheduled or denied those. This team and project structure is optimized for fast development with an heterogeneous team, not for reactivity.
Bus number of 1 would be nice to experience for once, I have yet to see a team with a bus number above 0...
Just to note, this wasn't a small system. At least a million lines of code and it was a decision support system. Bugs could theoretically cost lives (at least that's what we told ourselves, but it was kind of a stretch).
This was in a software shop back when we cut and distributed CDs. We had a 3 month release cycle which really enforced #2. I understand this is a lot harder when you are doing 2 week release cycles in Agile or something. With 2 week cycles, full regression for every release kinda goes out the window because there isn't time. (one of the down sides to Agile).
They should be. It's difficult to get quality experience if you're only designing by committee or executing on someone else's designs.
In other words, carving out niches for people is a great way to get your engineers to level up from junior to senior to beyond. They should, hopefully, appreciate the clarity in career progression also. They should be able to see themselves making bigger and more important decisions as they prove themselves.
My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you.
Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious.
I don't think it's one or the other. You need people to be able to jump in and contribute and improve things.
But you also need responsibility for the code as a body of work. If everyone with commit access owns the code, nobody does. As time goes on and it's a snarl of spaghetti code and slapdash design, it turns out it was nobody's job to make sure that didn't happen.
On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows.
> I don't hire or work with those people anymore. Neither should you.
If you are unable to work with some people by refusing to use a code architecture that would allow you to use them, does that really make you a superior project manager?
Don't get me wrong, different projects call for different processes. You don't code a blog framework in PHP the same way you program an embedded medical device. In some cases it is a bad idea to give free reign to individuals.
I simply notice that when it comes to abstracting your code, team structure and general project context is often more important than the project's function. In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API.
The alternative would have been to fire half the team and make a nicer code in twice the time. Not what I was hired for.
Seems less a problem with joint ownership and more a problem with poor leadership.
Seriously- i hate it when Hackers try to reduce theire co-workers to machines and enforce there personal taste as "programs".
If you are unable to deal with humans, to accept unimportant differences, why do you try to define the interfaces for humans on a project.
If all you can do is not enforce some poor coding standards then you are defacto not a lead.
That is not my experience. Sure, there will be some bikeshedding in the code reviews, but you get rid of most attack surfaces by agreeing on lint/formatting options and just delegating the task to a tool. For me, proper whitespace formatting was whatever gofmt spat out. Later clang-format with the agreed team-wide options and currently pretty-js. The team can instead focus on more important code issues like the overall structure or bugs in the reviews.
> It leads to never-enforced style rules that no one likes nor follows.
If no one likes, enforces or follows them, you can't really call them rules. If it is the mutual understanding that some style aspects are not relevant, what's the problem keeping it that way? There is no need to let that get in the way of enforcing some aspects of style in order to produce code that anyone in the team can easily work on.
> In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API.
IMO one of the best ways to train a new programmer is to have them work closely with more experienced people and with the same level of review scrutiny. I don't know about the project you are working on and its timeline, but in the long term I believe this pays off by turning newbies into good, independent programmers that produce readable and idiomatic code. And no one needs to argue about minor formatting details with the tooling available today. It's a self-imposed waste of time if anything.
But there needs to be a "Joes is responsible for the well functioning of microservices X1, Y2, Z3" - even if there may be 5 other people working on these same and others.
Also, people's "fragile" egos can be turned to your adavantage, as a manager or owner, but that is "black magick" and an oath I have sworn not to share its ways anymore ;) ...
That implies that Joe has some kind of authority over the 5 other people, I hope. Otherwise that sounds like a "responsibility for blaming only" situation.
>>> they'll throw a diva fit
? I'm not a native english speaker and although I get the general feeling, I don't get the exact picture this should paint in my mind... (and I bet it should be a funny one)
So "throwing a diva fit" is to get mad about something solely because it is not how you'd prefer it to be, regardless of what others think.
The alternative is to think up new architectures and team structures that allow more people more freedom to work.
Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your choices for the benefit of the wider team results in much better code.
This becomes more and more important as the team grows, as there are more feet that you can step on. Working on a large team is really different than a solo or small team. Large teams are as much about communication, mutual respect, and shared goals than writing good code. Unfortunately, communication takes time and energy, and necessarily slows down the entire process, but it's critical.
The Mythical Man Month lays this out nicely. The possible lines of communication in a N person team grows quadratically at N*(N-1), which explains why large teams are often far less efficient on a per-person basis than smaller ones.
in a professional context requiring collaboration, that's an asshole move, and people who do that sort of thing on a regular basis should be reprimanded.
The microservice approach has its own problems but hints toward a direction where teams are small and autonomous, with ground-up freedom on the architecture of their little service and free from draconian oversight. I'm not an advocate of microservices, but it's an approach that hints at something different.
A flat fully connected hierarchy is better for small groups, but it doesn't scale well as the number of lines of communications is proportional to the square of the number of people.
Quite literally, I think, it could be modeled as a vector space in linear algebra. Each signal is in frequency space, which can be found from the fourier transform integrating the temporal space over different bandwidth channels per sender. You get N² only if the message size is proportional to N, if you will.
a Fourier transform of channel
"everyone writes it" in the long term can still allow specific people to write/fix/augment/refactor/etc specific parts in the short to medium term. i think it's a good goal to never have a part of the code that less than two or three people can maintain, but preferably more (depending on size of team(s) and codebase(s), obviously). i think this generally results in better quality code, and higher bus factor is inherently a good thing anyway.
i used to be kind of against style guides and style checking. but a not-too-rigid set of style norms, the willingness to bend or discard them when justified, and a generally well-behaved group of people that can collaborate well and agree that shared understanding has a lot of inherent value... those things together can get you a good codebase where "everyone writes some of it", or at least everyone can deal with most of it, even if people might have areas of expertise. nowhere near a panacea, and not even necessary depending on the team, but it can be useful even if it means people give up style tics they love or tolerate ones they hate. it also mechanically eliminates a lot of the temptation to nitpick a whole class of things that probably doesn't deserve nearly as much nitpicking as it'd get in code review, because everyone thinks their own personal taste matters more than it actually does (me included, that's why i used to not like style guides).
all the above is much easier if everyone's able to keep their ego in check, be collegial, enjoy the challenge of justifying decisions and accepting constructive criticism, etc. i guess that can be an unfortunately difficult setup to come by, but i've been really lucky on that front, by and large.
> To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors.
if you have what i described above, peer level code review with team leads and managers for the occasional tie breaker should work fine the vast majority of the time.
> In this process, people lose autonomy and can't fully act on their own vision.
if you work on a team, you have to work toward shared goals and vision. if a person wants to fully act on their own vision, they should be self-employed in a company of one (though they'll still be subject to market forces). if you're collaborating, you're necessarily involved in a shifting balance of autonomy, delegation, and being delegated to (which is often but not always where the autonomy comes in).
But with collective code ownership it's still useful to designate a couple of developers as "stewards" for each major component. They don't own the component, but they take responsibility for training other developers on the internal design, making suggestions on refactoring, and reviewing design proposals and code diffs.
Also, most of the time, small self-contained units of code are trivial to fix if the original developer goes under the bus, because small means any half-decent developer should be able to read the code[0] and understand it, and self-contained means you're not afraid to change things because you can easily track how the effect of your changes propagates.
--
[0] - an activity that people often shy away from, or are afraid of. Can't for the love of God understand why.
Having a lot of individual pieces that connect using simple, straightforward interfaces is much more flexible and maintainable in the long run - it's the same reasoning that draws people to microservices.
Is this necessarily a bad thing? I know this quote and it always made a lot of sense for me. But I never understood where exactly is the problem, and why one should go to great lengths to avoid this.
Moreover, in this concrete example, isn't assigning modules to individual developers (as opposed to collective code ownership) essentially the same? i.e. structuring the code along the organization communication structure?
Then, ignore that feeling until you get proof. If you've kept your code simple and clean reacting to a lack of abstraction is relatively easy, at least compared to what digging yourself out of the wrong abstraction is like.
We sometimes lose sight of this because when we learn that abstraction is necessary, and see how beautiful it can be, we forget that it is an extra layer of mental indirection.
TLDW: "refactoring your way out" from a simple but too short-sighted design might take a ridiculous amount of work, compared what would have been necessary if you knew what a "correct" design for this problem was.
https://mobile.twitter.com/KentBeck/status/25831623306839654...
> "Any problem in computer science can be solved with another layer of indirection"
Otherwise, good point – I did not think of this.
I realized before writing it that there I would never use this script after today, no one ever had to see it, and it would never get version controlled. So i just wrote it in the quickest "get it functional for 95% of cases and throw an error otherwise"
It was kind of fun. Multiple parts had godawful big-O run times, multiple anti patterns, etc. But none of that mattered since it would never be used on a massive file and would never be in production. It took me back to that phase where i was young and doing pet projects and i could be as selfish as possible.
There’s a trade-off between time to completion and designing debt-free code, and I think that one small mantra helped me find the right balance. And let’s be realistic, the only debt-free code is code that is never touched by new implementation.
1. Make it work 2. Make it work fast 3. Make it work well
In that order.
Better finish 80%, than miss 100%.
Sounds like programming in go :)
PS. It's a joke, I enjoy go myself.
I'm really talking about the lines in your code, they're structured so well that they will help forge more code in the middle and later parts of your code life.
Like any good video game, if you produce good tools in the beginning to produce levels, modes, multi-player games, etc... then you will produce something great.
If you don't care about what you're writing, then it will become a huge mess and you will either give up or your users will give up. Or once in a life time, the mess you created will still be fun enough that everyone will start playing it, deadmau5 will make a tattoo of it and Microsoft will buy you out and you will have the most expensive house in the world/LA.
As you start filling out the breadth of your design a time will come when you know an idea is going to work, and you have more knowledge to inform your tool.
Of course to what extent you should approach the coding breadth first vs depth first will depend on how clear of an idea you have for the design. If you were just doing a near-clone of Doom and you have done this before then maybe you can just rabbit hole pretty deep from the get go.
"If you don't know which way is better, do it both ways and compare."