[MajorBee]

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.

[signa11]

``` ... 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.

[cercatrova]

That's why I like the other TDD, type driven development. Lay out all your types and make unwanted states literally unrepresentable. For example, if you're making an email sending service, you can have an EmailAddress type that is represented underneath by a string and the only way you can instantiate a new EmailAddress is via the constructor function which will take a string, parse it and validate it as an email, and if it works, it returns the EmailAddress type, otherwise it returns None (if you're using a Result typed language). And the sender function only accepts an EmailAddress, not a string, so if your EmailAddress constructor returns None, you literally can't send the email, by design.

A good video on this concept: https://www.youtube.com/watch?v=1pSH8kElmM4

[signa11]

that ‘technique’ had a name ? never realized it. thank you kindly!

[js8]

> 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.

[ggeorgovassilis]

> 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.

[pm90]

Heh, this is an interesting perspective and Im realizing some assumptions Ive come to rely on.

When designing a system or writing code, my instinct is to write it in a way that makes it clear, easy to work with and change down the road, because Ive seen code that is not structured this way and working with it is hell. I consider myself somewhat lucky to have worked in teams that allow for this.

If however I wasn’t fortunate enough, or just not paid enough even, or the work culture didn’t exist or was purely transactional, I would likely change my approach to fit that situation.