A high-velocity style of software development
mihaiolteanu.me
mihaiolteanu.me
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.
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.
can -> can't
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.
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.
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.
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.
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.
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?
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.
I can only think of the reason of pair programming and both users editing at the same time.
https://www.reddit.com/r/emacs/comments/1glqfa3/my_company_d...
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 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.
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.
"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!