I have grown to dislike "jugaad" solutions to problems (unless it is forced onto the problem through sheer necessity), mainly because -- if left unchecked -- it fosters a culture of doing just barely enough to meet minimum requirements and no adherence or even ambition to achieving excellence and craftsmanship.
I recognize that jugaad solutions are usually not what people necessarily want to resort to, but are frequently adopted because of lack of viable alternatives. In such situations, more power to us / them! I'd call that being resourceful though. Aspiring to arrive to the jugaad solution to problems when better ways of doing it are within reach though, that's where I draw the line.
```
... mainly because -- if left unchecked -- it fosters a culture of doing just barely enough to meet minimum requirements and no adherence or even ambition to achieving excellence and craftsmanship.
```
that is exactly my major gripe with TDD style development. It just seems too /incremental/ and smacks of prioritising getting /specific/ features done, rather than finding the best overall design. with this tactical style development, it is quite easy to end up with a mess.
> it fosters a culture of doing just barely enough to meet minimum requirements and no adherence or even ambition to achieving excellence and craftsmanship
This criticism can be raised against Agile as well, but I think this attitude ultimately comes from utilitarian (or MBA) perspective, which puts monetary profits above human or engineering excellence.
> I have grown to dislike "jugaad" solutions to problems
Maybe it takes an outsider's view to appreciate jugaad. I certainly didn't on my first encounter.
> no adherence or even ambition to achieving excellence and craftsmanship
I agree - jugaad isn't the place for planned evolution, so skills that transcend the immediate needs for delivery never form.
> Aspiring to arrive to the jugaad solution to problems when better ways of doing it are within reach though, that's where I draw the line.
I think that most developers in India aren't even aware of the jugaad methodology, it's just the way things are done. When I was first exposed to jugaad I mistook it for sloppiness, but it turned out that both deliverables and the organisational setup itself is extremely anti-fragile: it's always easy to add or remove a part, although refactoring is hard.
"Jugaad" is a cultural attitude that is hard to explain outside the Indian context. (Even literally, as the "d" sound in the word has no counterpart in English phonetics. It's similar to "dh" but not quite.) The closest literal translation would be "somehow, cheaply, without deep thought".
There are class connotations. Jugaad is something forced onto people by poverty. It's hallmark is messy, janky and easily breakable setups that have been cobbled together by both necessity and lack of resources. Wealthier Indians would not turn to a "jugaad" solution for their needs.
While the principles in the post (humility, openness, frugality) jive well with the Agile philosphy, I'm not so sure that "jugaad" is the idea I'd want my software to embody.
The 'd' here actually transliterates one of the two hindi/common indian language 'R's. One is the dental R (र), pronounced by putting the tip of your tongue at your teeth, and the other is the retroflex R (ड़), pronounced by putting the tongue at the roof of your mouth. It is a cross between a 'd' and an 'rh' sound. The retroflex 'd' (ड) is pronounced in a similar manner.
The second 'R' is used in jugaad here (जुगाड़), and it means to "cobble together" or "makeshift," which exacty what it is: makeshift, hastily cobbled together work done to get the weight off one's shoulder as soon as possible.
It can also simply mean "collect" or "collection", but it means the above in this context.
Edit: There is another 'R' (ढ़) which is pronounced like a (ड़) with an additional 'h'.
English has the phrases “jerry-rigged” and “held together by duct tape and baling wire” which, as far as I can tell, mean the exact same thing and were born out of similar impoverished circumstances.
One thing people all over the world have in common is that our ancestors were dirt poor not very long ago, so I would expect this concept to be universal.
I agree. I liked that this article apparently gave a name to what I would call "product development under uncertainty". But then I looked jugaad up further and it's not the same thing at all.
Jugaad seems to have more of a connotation of not doing things properly, rather than embedding options. Very different things!
Jugaad is a good thing if that is kept as just the start and things don't end in Jugaad.
Personally, I'm not a Jugaad person. I won't suggest glorifying or encouraging Jugaad in any way except to get things started but a parallel plan to move back to normalcy/excellency should be in the work as soon as it starts.
Too many a things have failed in India because it was Jugaad-ed for too long. Jugaad is an Indian thing and we love it for various reasons. https://en.wikipedia.org/wiki/Jugaad
Edit/Update: I kinda usually narrates to the team I work with to -- experiment and jugaad like the Indians, have the discipline of the Japanese, and the finesse to deliver like the Germans.
No cultural misappropriations intended and I'm still working on making that better with more cultures inclusion.
First time I've seen this in the context of software development.
"Jugaad" is hard to translate: it's usually associated with hacking up a cheap replacement for something expensive. Roughly translates to "we'll manage something."
Some examples:
1. A fruitpicker made out of a 2 litre plastic bottle whose base has been cut to form a claw.
2. A mobile water dispenser made from a can mounted on a trolley, with a tap operated using a bicycle cable.
> 1. A fruitpicker made out of a 2 litre plastic bottle whose base has been cut to form a claw.
Which is, I think, an excellent reminder to not be dogmatic about software delivery. Many projects never start (and hence much value isn't generated) because of theoretical disputes about how/how much/what analysis should pretext development, which development style and which tools and frameworks should be used.
Reminds me of the Chinese "chabudou" meaning "almost" or "not much missing". This attitude is painful and costly in hardware development - you save money and time now, but it costs you a lot more in the long run (e.g. support and RMA costs). But it is in software development where I found it really devastating.
Things like people not using version control but creating lots of "bak" and "copy" files. Using tools from hacking boards on your own software because we don't bother making a proper build. Unit tests are seen as a waste of time. API design is seen as an academic luxury.
I mean, I am all for agile. And for building MVPs without unneccessary abstractions and fluff. And heroic hacks that save the day. But "good enough" or "duct tape" should never become your main development methodology.
At first I thought this article was going to be a parody. But as I kept reading I cannot believe that this article is actually serious!
I am very doubtful if the said properties of "jugaad" in this article are correct. I don't see any references that establish the meaning of "jugaad" for us! Right now we just have to take the author's word for it.
Maybe someone from India here can correct me but if I see Wikipedia "jugaad" seems to be the Indian version of "hack". A hack can sometimes be good but I know for sure a whole working product real people rely on should not be made out of hacks (no matter how much frugality it brings to innovation).
I am getting really worried now that in another 5 years we are going to have "jugaad consultants" and "jugaad certifications" telling us how to develop software. Sounds far-fetched? Think again! 20 years back I would have never imagined in my wildest dreams that there would be such creatures as "agile consultants" telling us to play "planning poker" and assign fibonacci numbers to our "stories"!
Sounds like it might work for MVP but not in the long term scaling of a product. Let's say you use Wordpress + plugins to make a quick MVP but your target is enterprise scalable CRM application with a lot of custom forms.
* Humility - yes it works now
* Openness - let's rewrite everyrhing now from scratch
* Frugality - rewriting is far from small expense
Having worked in companies with a variety of skill levels, I find the higher skill you go, the less hacked together things get. While I honestly don't think Agile has to stand in opposition to good design principles, most treat it as though it does in practice. Whereas in less Agile orgs, I've worked with 20 year old systems that are still maintainable and fulfill their purpose well, in Agile orgs it feels like every system more than a couple years old has become spaghetti.
I can't 100% vouch for causality - as I said, the skill differences between the average developer in some of these orgs are immense, but it says something to me that all the more talented companies I've worked in tended not to go down the "fast and hacky is fine if you iterate" path.
Please don't do Jugaad. I haven't met a single software engineer from India who thinks Jugaad is a good thing. It's not. If it's done it's meant to surmount bureaucratic or financial hurdles, not as a software development methodology.
And then nothing works because of the combinatoric explosion and very low average quality of a library.
Then it takes a team of 20 to maintain a relatively simple project which manages to employ spring, guice, akka, cats and zio at the same time. Then the business closes because the funding is exhausted, product is too unstable and demands are not met.
imo, i can compare it to laziness. xp is all about being lazy. but the context matters here.
one lazy is just coping pasting stuff.
other is drying as you go. i have already written this line, why am i reapting it again. let me dry it. extract it, so next time i need not.
no two lines in my code should match. if they do extract.
i am lazy here. cause i don't want to copy paste next time.
i am lazy and will just dry.
second lazy is more what lazy means.
There are probably many ways to do one thing. I love XP primarily for the box of procedures and tools. Which is the contrast to jugaad where there are no methods or tools.
[+] [-] MajorBee|3 years ago|reply
I recognize that jugaad solutions are usually not what people necessarily want to resort to, but are frequently adopted because of lack of viable alternatives. In such situations, more power to us / them! I'd call that being resourceful though. Aspiring to arrive to the jugaad solution to problems when better ways of doing it are within reach though, that's where I draw the line.
[+] [-] signa11|3 years ago|reply
that is exactly my major gripe with TDD style development. It just seems too /incremental/ and smacks of prioritising getting /specific/ features done, rather than finding the best overall design. with this tactical style development, it is quite easy to end up with a mess.
[+] [-] js8|3 years ago|reply
This criticism can be raised against Agile as well, but I think this attitude ultimately comes from utilitarian (or MBA) perspective, which puts monetary profits above human or engineering excellence.
[+] [-] ggeorgovassilis|3 years ago|reply
Maybe it takes an outsider's view to appreciate jugaad. I certainly didn't on my first encounter.
> no adherence or even ambition to achieving excellence and craftsmanship
I agree - jugaad isn't the place for planned evolution, so skills that transcend the immediate needs for delivery never form.
> Aspiring to arrive to the jugaad solution to problems when better ways of doing it are within reach though, that's where I draw the line.
I think that most developers in India aren't even aware of the jugaad methodology, it's just the way things are done. When I was first exposed to jugaad I mistook it for sloppiness, but it turned out that both deliverables and the organisational setup itself is extremely anti-fragile: it's always easy to add or remove a part, although refactoring is hard.
[+] [-] gandalfgeek|3 years ago|reply
There are class connotations. Jugaad is something forced onto people by poverty. It's hallmark is messy, janky and easily breakable setups that have been cobbled together by both necessity and lack of resources. Wealthier Indians would not turn to a "jugaad" solution for their needs.
While the principles in the post (humility, openness, frugality) jive well with the Agile philosphy, I'm not so sure that "jugaad" is the idea I'd want my software to embody.
[+] [-] pilsburyfan|3 years ago|reply
The second 'R' is used in jugaad here (जुगाड़), and it means to "cobble together" or "makeshift," which exacty what it is: makeshift, hastily cobbled together work done to get the weight off one's shoulder as soon as possible. It can also simply mean "collect" or "collection", but it means the above in this context.
Edit: There is another 'R' (ढ़) which is pronounced like a (ड़) with an additional 'h'.
[+] [-] monster_group|3 years ago|reply
There's nothing special about "Jugaad". It's same as white trash repair. All societies where resources are limited have some form of "Jugaad".
[+] [-] pjscott|3 years ago|reply
One thing people all over the world have in common is that our ancestors were dirt poor not very long ago, so I would expect this concept to be universal.
[+] [-] kqr|3 years ago|reply
Jugaad seems to have more of a connotation of not doing things properly, rather than embedding options. Very different things!
[+] [-] thou3iou42o34|3 years ago|reply
'Move fast and break things' is the high-class version IMO.
[+] [-] Brajeshwar|3 years ago|reply
Personally, I'm not a Jugaad person. I won't suggest glorifying or encouraging Jugaad in any way except to get things started but a parallel plan to move back to normalcy/excellency should be in the work as soon as it starts.
Too many a things have failed in India because it was Jugaad-ed for too long. Jugaad is an Indian thing and we love it for various reasons. https://en.wikipedia.org/wiki/Jugaad
Edit/Update: I kinda usually narrates to the team I work with to -- experiment and jugaad like the Indians, have the discipline of the Japanese, and the finesse to deliver like the Germans.
No cultural misappropriations intended and I'm still working on making that better with more cultures inclusion.
[+] [-] Brajeshwar|3 years ago|reply
I don't think there is a way to edit comments after a while. I saw this thread after I went away from my HN's burst activities.
[+] [-] jcoder|3 years ago|reply
[+] [-] pm90|3 years ago|reply
EDIT: the rest of your comment is ok, just drop the last bit.
[+] [-] rish1_2|3 years ago|reply
It is unnecessarily fantasized into a positive light.
Startup culture may be described this way but the context is completely different and vision as well.
[+] [-] dang|3 years ago|reply
Jugaad, an Indian Delivery Methodology - https://news.ycombinator.com/item?id=24459888 - Sept 2020 (63 comments)
[+] [-] SanjayMehta|3 years ago|reply
"Jugaad" is hard to translate: it's usually associated with hacking up a cheap replacement for something expensive. Roughly translates to "we'll manage something."
Some examples:
1. A fruitpicker made out of a 2 litre plastic bottle whose base has been cut to form a claw.
2. A mobile water dispenser made from a can mounted on a trolley, with a tap operated using a bicycle cable.
[+] [-] ggeorgovassilis|3 years ago|reply
Which is, I think, an excellent reminder to not be dogmatic about software delivery. Many projects never start (and hence much value isn't generated) because of theoretical disputes about how/how much/what analysis should pretext development, which development style and which tools and frameworks should be used.
[+] [-] SanjayMehta|3 years ago|reply
2. https://www.youtube.com/watch?v=oDejH09_0to
[+] [-] rhuru|3 years ago|reply
[+] [-] captainmuon|3 years ago|reply
Things like people not using version control but creating lots of "bak" and "copy" files. Using tools from hacking boards on your own software because we don't bother making a proper build. Unit tests are seen as a waste of time. API design is seen as an academic luxury.
I mean, I am all for agile. And for building MVPs without unneccessary abstractions and fluff. And heroic hacks that save the day. But "good enough" or "duct tape" should never become your main development methodology.
[+] [-] distcs|3 years ago|reply
I am very doubtful if the said properties of "jugaad" in this article are correct. I don't see any references that establish the meaning of "jugaad" for us! Right now we just have to take the author's word for it.
Maybe someone from India here can correct me but if I see Wikipedia "jugaad" seems to be the Indian version of "hack". A hack can sometimes be good but I know for sure a whole working product real people rely on should not be made out of hacks (no matter how much frugality it brings to innovation).
I am getting really worried now that in another 5 years we are going to have "jugaad consultants" and "jugaad certifications" telling us how to develop software. Sounds far-fetched? Think again! 20 years back I would have never imagined in my wildest dreams that there would be such creatures as "agile consultants" telling us to play "planning poker" and assign fibonacci numbers to our "stories"!
[+] [-] 4silvertooth|3 years ago|reply
[+] [-] pfoof|3 years ago|reply
* Humility - yes it works now * Openness - let's rewrite everyrhing now from scratch * Frugality - rewriting is far from small expense
[+] [-] JustLurking2022|3 years ago|reply
I can't 100% vouch for causality - as I said, the skill differences between the average developer in some of these orgs are immense, but it says something to me that all the more talented companies I've worked in tended not to go down the "fast and hacky is fine if you iterate" path.
[+] [-] qwerty456127|3 years ago|reply
You can't expect a "modern web" app to survive this long. Chances are it will become unbuildable (because of the dependency hell) much faster.
[+] [-] gautamdivgi|3 years ago|reply
[+] [-] stonecharioteer|3 years ago|reply
[+] [-] pshirshov|3 years ago|reply
And then nothing works because of the combinatoric explosion and very low average quality of a library.
Then it takes a team of 20 to maintain a relatively simple project which manages to employ spring, guice, akka, cats and zio at the same time. Then the business closes because the funding is exhausted, product is too unstable and demands are not met.
We prefer to choose the libraries wise.
[+] [-] stonecharioteer|3 years ago|reply
[+] [-] rajatsx|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] shmde|3 years ago|reply
[1] https://old.reddit.com/r/redneckengineering
[+] [-] duckydude20|3 years ago|reply
one lazy is just coping pasting stuff. other is drying as you go. i have already written this line, why am i reapting it again. let me dry it. extract it, so next time i need not. no two lines in my code should match. if they do extract. i am lazy here. cause i don't want to copy paste next time. i am lazy and will just dry. second lazy is more what lazy means.
[+] [-] cratermoon|3 years ago|reply
[+] [-] ggeorgovassilis|3 years ago|reply