There are circumstances when one has to "get things done" quickly. It's sad, but it's life.
How much pragmatism is still okay and how much could ...
For further actions, you may consider blocking this person and/or reporting abuse
"compromises in design can save a lot of effort, but code must be as clean and efficient as possible."
The above is a vague sentence, such as: "Do it fast and perfect". Yes, unicorns.
Your point is a daily debate in my mind. I try to be as accurate as I can't in the design. Yet, that sometimes brings a big burden in time. Somehow, I rarely drop design in favor of 'pragmatism'. Maybe because I am developing academic projects, which may be (I don't know) don't have those strict time restraints as companies do. However, I do believe one should aim at integrating arch design deep into his/hers medulla, so it comes naturally as you type, without requiring demanding slots of your time.
Also, in my projects, every time I dropped design over 'pragmatism', I ended up regretting it later.
It can also happen that one becomes too narrow-sighted with arch and ends up over-engineering too much. That also happened to me, mostly when I was more inexperienced.
So... answering your question straight, I believe pragmatism is too much and that becomes an excuse for laziness, either it is in avoiding learning how to design faster or simply avoid working.
Honestly, I believe that one can develop skills that will render proper design almost a naturally occurring process in your programming.
Good post,
Cheers,
But this is often not about skills, it's about accepted shortcuts in design.
That is, it's not "I can't", rather it's "I don't want to".
We should find a way for projects managers to understand and accept the importance of a technical debt, too.
Do you have any experience regarding this? It works probably a bit better on academic projects, am I right?
I like your answer, it's pretty much what I think, too. Thanks!
Generally, academia is governed by very different rules. Groups that can apply meticulous arch principles will do it. Others will just focus on speed because that is the aim of the research. It is very difficult to put everyone in academia or judge everyone by the same rules. And also depends absolutely on the desire and coding style, of the developer.
In my case, I am the sole developer of the whole project. I am my own project manager, the daily developer, the beta testers, the bug corrector, one-man-team. So it is up to me to find the equilibria between dedicating a lot to arch or not. Usually, I am paranoid and won't rest until I have perfect architectures I can come up with. Obviously, that has a cost. Actually, I rarely care about making quick prototypes because we already know it will work; it has been demonstrated mathematically at some point in the past. Hence, I focus, from scratch, on the best arch I can achieve. Anyway, suppose I fail in the design. In that case, my programs will rapidly run into a dead end because projects continuously require new additions to the software. Weekly! So, I have become quite paranoid with design, which inevitably collides with performance. And back-and-forth.
Altogether, I am not a computer scientist. I am a biochemist who self-taught programming by passion. Which sometimes makes things more difficult because I feel without references and lacking some hardcore concepts on how computers work, or references regarding culture-known assay comparing implementations or strategies.
Also, I have no bias. Which sometimes slows down development; other times it is a benefit. For example, some people are all-in to OOP. OOP everywhere. Others are FP-everywhere (these are very rare). Everyone has a bias. Having a bias has the positive aspect that you won't lose time looking for answers. You will just apply your hammer everywhere. The counter effect is that biases become short some times. However, if one does not have a bias, one might get lost some times trying to find the best hammer for the task, ending up testing all hammers before the actual implementation takes place. I am in this second situation most of the time. :-) Which I like, actually.
Regarding pragmatism, I am a Python dev. And Python quite embraces every paradigm. So I am balancing my code know mixing OOP with FP in the best pragmatic manner I can.
I believe that when one has the concepts really plugged in (really learned) into one's behavior than there is no "I don't want to". It will become the only way you know how to code. In my case, it took me quite some time to understand some strategies, but once I got them deep into my mind, then, I could not use the outdated ones again; they won't simply reach my fingertips.
Good talk!!
The Project Management Triangle.
• Good (🚢)
• Fast (🚤)
• Cheap (🚣)
The boss says, "Pick three!"
The optimist says, "Pick two."
The pessimist says, "Pick one."
The cynic says, "Pick none."
How do you define pragmatism in this context? To me it's always on the line of: we will not pursue the ideal solution because the cost of doing so against the immediate needs risks upending the relationship with customers.
It's often about quick and dirty to get ahead but if you're ever considering whether pragmatism is driving the product into the ground then you're not talking pragmatism. You're talking failure in engineering leadership to get buy-in for reasonable solutions.
Whole > Part
You can still end up with a project that feels like a part if you only get things done and never perfect. I've heard it too often: the legacy project must be redesigned - which will usually take forever.
Would you call the situation I described above a violation of system thinking? :-)
My favorite quote on programatism by Keynes:
Cover photo by Javier Allegue Barros