This could use with being a bit shorter and maybe carved into pieces because the main idea is very powerful and the author has seen a thing or two clearly!
That being said although I agree with many things the author said, I think this phase goes a bit different:
> "You will waste so much time! Let's have a grand plan and write the perfect solution right from the start, ehh?"
The reason why bosses/ non technical people want to talk so much before and write so much non-code is because they can. If they could write code they wouldn't mind , but the "talking" phase is the only one where they can contribute and so to feel useful they actually delay everything.
This comes from an observation that difficult problems / projects sometimes were fixed much faster than easier problems.
Why? Because an easy problem is understood by everyone, so everyone has an opinion, so now we have to hear all the uninformed opinions and debate all the obviously-not gonna-works. But hard problems, they have two great properties, most people won't even understand the problem, and even if they do, they won't know what to do. So then you get one or two guys to actually fix it undisturbed.
Not only it's slower to have to deal with uninformed opinions, the outcome is often worse also, because for politeness and to avoid awkwardness you end up with an "average" of the opinions, but if majority of those are uninformed you just got a worse solution by talking.
It is shorter than what I've had initially, really. And yes, these are a bunch of ideas I try to make clearer for myself, as well. Like, there is a feeling inside and
you've seen things and experienced different scenarios and now you try to put them into actual words that makes sense, as a whole. If you are successful at that, that's another story. Add to that that other people's experience are different and they come from different backgrounds, things get even messier. I think there was a piece from antirez a few days ago where he was being surprised, among others, on how much harder writing is, in general, than coding. I feel the challenge of that sometimes.
That being said, I appreciate your answer and insight.
Edit: why did you stop writing, if I may ask you? (I'm assuming now that not publishing for the whole world to see equals not writing at all, which might not be the case)
I discovered HN comments and that fact that if I write something dumb on my blog nobody tells me, but if I write something dumb on HN everyone downvotes and corrects me, so I appreciate the direct feedback more than the "publishing properly" while scratching the same itch.
I have several comments I bookmarked to myself that I consider "my blog post on subject X". Also it's still possible to know what I think about stuff by going through my profile as if it were a blog, but people don't do that so it's sort of privacy while in public as well.
How do you know you're building the right thing? Who is paying your salary? Are you regularly talking to all stakeholders? Congrats, now most of your time is spent in meetings. You don't want that? Now you have to talk to project and product managers, who don't want to reinvent the wheel and thus impose structured information exchanges like planning on different time horizons (sprints, quarterly roadmaps, ..).
> Now you have to talk to project and product managers, who don't want to reinvent the wheel and thus impose structured information exchanges like planning on different time horizons (sprints, quarterly roadmaps, ..).
The people who don't write code also have an inherent bias to make their own contribution look as big as possible though because they want the most money. So do the people who write code as well I guess, which is the whole exercise of trying to make what we do as relevant as possible.
I don't think OP is saying don't talk to anyone. I think he is saying if there are three identified paths forward, stop spinning your wheels or have some non-technical person make a choice for you, implement all of them and let the data decide.
Disclaimer: I only skimmed the article and didn't read it properly. I felt like it is what the author would want me to do.
No, I'd like you to read the whole of it. Or, at least, every author lies to themselves that they have the most devoted of readers.
But yes, you are right with your summary. It is based on an observation that some of the solutions I've seen developed are developed inside our own heads only. Or are written down in documents or slack channels or meetings where we talk, we agree on things but they are not enforced anywhere. Or where we dream "what if's" scenarios, put all those side by side and vote, based on our power of imagining the outcome, and decide what to next implement and spend our time with.
And part of the problem, and I say part as I don't have access to everyone's environment to see how they work at their computer now that we work from home, but part of that is a real fear of the computer (or lack of mastery, I donno), thus the bits about changing code often, some ideas on how to achieve that and make the environment you're using to write code, explore the project and your ideas your own, regardless of how it looks from the outside.
As an extreme example, one client was sending us both the authentication library as .c and .h files to be compiled on our side and an add-on to be installed on a tool we were already using. When there was a new version of the .c and .h files, which always happened as this authentication feature was under active development, the add-on changed too. There were instructions as PDF files on how to install this add-on, which were slightly different every time. When the project started up, before one could send any commands to it, the authentication procedure had to be successfull.
My thinking was that, since I don't work on that part of the system and the features that I'm responsible for only work after the authentication was successful anyway, I can identify the part of the code that does the authorization and hard-code an authorization successful implementation, which was simply returning <q>true</q> from the correct
function. I would thus reduce the number of steps needed to reload the system after a code change and thus reduce the reload time. In short, I would just assume the authorization worked and concentrated only on my stuff. I didn't commit this code, of course. But to my surprise, even though I've presented this to colleagues and even PM, the reply was that well, we sorta have to work with the whole system and make sure the whole system
works. And yes, we did that, only on our daily activities we didn't have a reason to test the authentication part every single time, dozens of times per day since we didn't change
it, we worked on the part of the code that comes after authentication. But no luck. So a lot of time was spent and is spent with these steps.
I say "an extreme example" as automotive software seems to e to be a special example. I wrote about it on another post on my blog. It got pretty long and uncovered all the messiness. But that's another topic.
I have a problem similar to this but not exactly the same. What I would like is for the whole company (assume a run off the mill ecommerce store for this example), regardless of the company size to be able to fit all (I guess almost all) their code on one physical machine (or I guess a set of physical machines). Let's assume we can stub out any external dependencies such as vendors or customers.
We should be able to run the whole system end to end and have a coherent story. We should be able to pull changed from production and be able to run it on this one machine and verify that all the steps work exactly as expected.
I joined a team that was getting into micro services. They enthusiastically told me about their domains and bounded contexts and how I had access to all the repos and could run them on my machine. So my question was how can I run them all together on my machine end to end and the answer was silence as if I had kicked a baby.
Edit: thank you for your added context with the authentication library. It makes sense why the architects and lead developers were not interested in having the whole system run end to end on a developer machine. They want to have that tight "inner loop" and have developers working in that inner loop and not worry about the rest.
This. If you're not a small startup, the number of stakeholders who need to get aligned is the #1 bottleneck. The only way to get velocity while avoiding the meetings is getting as many stakeholders as possible to put their concerns in code: Finance wants to set a budget? Set up budgetary alarms. Product wants to know whether changes affect usage? Add metrics. Security wants to keep things hardened? Policy-as-code, auto-reconciliation, etc. Compliance wants assurances? Reporting, scanning, dashboards, tag policies, etc. etc.
Running out into the desert without knowing if anyone is going to bring you water may help you feel better than standing in place, but it's also a sure way to die.
It doesn't haveto be a startup. Small companies and agencies/consultancies can offer talented developers a lot of freedom and agency to deliver projects more rapidly.
Of course you haven't got the guardrails of bureaucracy and blamelessness of multiple levels of stakeholders, but some people really thrive and deliver great software in that environment.
I agree with some of what the author says (building at least one prototype before carving a plan into stone is usually a great idea), but I think affordances for teamwork are missing. The author proudly reiterates how much of their development process exists only locally, with key artifacts like mocks and prototypes being inaccessible to team members. I think one of the most effective ways to increase velocity is to structure your work so that 2-3 other people can work on it with you. I feel like that would be a more productive discussion than some of the nuts and bolts stuff this article dives into (side effects or ifElses or what have you).
Yes, `2-3 other people can work on it with you` would be splendid. But then you have to be on the same page with your colleagues on how to go on about doing things. You know how that goes, when good ideas are then made mandatory and all the team must follow suit. Then the original motivation is kinda lost in the background and then part of the team only does the moves because "someone told me to".
If you say, yes, `2-3 other people...`, let's get together and do this thing, approval or no approval, then we might be getting somewhere.
As an extreme example, if I'm using Emacs, and assume it offers some advantage in the project development velocity department (ignoring any reasons as to why, for the sake of the argument) but cannot convince the other team-members to use it, should I stop using it?
There's a difference between working in lockstep with every single other teammate and making your work available to other people. The former is sometimes the ideal, but the latter is always achievable.
I am maybe the only Emacs user in an eng org of 100 people. But my work is compatible with that of the VS Code and Vim users, of course.
> Yet, the alternative, the rich man's debugger, introduces another tool into the project, something I try to avoid
I would not call this introducing a tool into the project. The debugger is not part of the project. I would call this utilizing the tools that are already built into your editor to make yourself more productive, instead of kneecapping yourself to only printing things.
Talking to the main point of that paragraph - using a debugger and having hot reloads are not mutually exclusive. You can use hot reloads to rapidly see live changes, then use breakpoints to inspect state if required. Additionally, that a debugger "cannot change the implementation" is not universally true; this varies by language and debugger, see Erlang/Elixir.
When people say things like this, it makes me think they simply lack the knowledge on how to effectively use a debugger, or they (or their language ecosystem) have not invested in good tooling.
One way to look at it is that, if I rely on a debugger and the style of development it promotes I will not try to make those reload times shorter for my project and that will result in a different style of developing software, tool-wise.
One thing I saw happen in C development is, because the projects were so big and a reload after a code edit would also require a re-initialization phase to bring you back to that point in the code you were before you made the change, is that at one point you introduce the scripting language the debugger offers. Small files, at first, to set-up global state, to call the right functions, etc, since the project was meant to be debugged as a whole and not worked on in individual buildable and runnable code files. Like the classic maths library, for example, extracted into a different file and developed individually, without taking into account the rest of the project. That speeds up the development velocity, for example. And you can test it against locally available sets of data, like lists, matrices and what have you.
Yes, I've used the Common Lisp debugger. But I also use JavaScript to pay the bills, so to speak. I've wrestled for months on end with the nodejs debugger and its integration with Emacs. Lost connections, wrong configs, random errors, etc.
I still think the debugger is an extra tool, like a code editor is an extra tool, the finished product doesn't have any trace of what code editor you've used in the process. So if you can make your life easier without one, why not, there is no absolute requirement that you should use a debugger, for our example.
Anyway, that is my reasoning. It might be wrong, it might be right, but it's taken from actual practice. Some people might have different experiences and that is fine, too.
one thing i’d add that works well in javascript that is similar to “eye level is buy level”
and that is “hoist the system”
the important things that any file does is at the top.
the things those things depend on are either imported from packages at the top of the file or hoisted from functions below.
the things those functions depend on are hoisted from below them and so on
this makes every file in a system easy to grok because the first things are the business needs and as you scroll down, you get into the weeds and the implementation details— important things, but conversationally irrelevant things— this paradigm makes cross functional collaboration more effective as it drives engineers to understand business context with literal forcing functions.
Yes, I do this kind of thing in JavaScript, too. I actually forgot it is a feature. Not all JS projects I work on take advantage of it in this way.
"conversationally irrelevant things" - nice way of putting it. Important things, because they are there, the project is built on them but they are actually just details from a requirements or project-feature-wise point of view. Nicely said!
That being said although I agree with many things the author said, I think this phase goes a bit different:
> "You will waste so much time! Let's have a grand plan and write the perfect solution right from the start, ehh?"
The reason why bosses/ non technical people want to talk so much before and write so much non-code is because they can. If they could write code they wouldn't mind , but the "talking" phase is the only one where they can contribute and so to feel useful they actually delay everything.
This comes from an observation that difficult problems / projects sometimes were fixed much faster than easier problems.
Why? Because an easy problem is understood by everyone, so everyone has an opinion, so now we have to hear all the uninformed opinions and debate all the obviously-not gonna-works. But hard problems, they have two great properties, most people won't even understand the problem, and even if they do, they won't know what to do. So then you get one or two guys to actually fix it undisturbed.
Not only it's slower to have to deal with uninformed opinions, the outcome is often worse also, because for politeness and to avoid awkwardness you end up with an "average" of the opinions, but if majority of those are uninformed you just got a worse solution by talking.