Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doing things the wrong way to get the right result

madebymany.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Doing things the wrong way to get the right result

#31

Post by supergeek133 »

It may not be absolute advice, but certainly applicable in many companies.

For instance getting a new environment setup inside a company that is a big Azure customer. There are forms, reviews, cost centers, and more reviews. Even to get a QA environment. I have access to a subscription, and more than once I've just set things up for people.

We're talking potentially weeks of time lost just to start working.

Not to mention the seemingly severe lack of willingness to prototype within an organization these days.

Re: Doing things the wrong way to get the right result

#32

Post by lgunsch »

larrik wrote: post #7

The problem with this approach is when they say "okay, we'll have an intern do the manual keying each week and use the prototype as the finished product. Thank you, goodbye." Or the fact that it looks 90% done, so the idea that you did it in 2 weeks means you are just days away from completion, right? Sometimes the reasons for not hacking stuff together can be quite political, both for internal projects and for consu…

"okay, we'll have an intern do the manual keying each week and use the prototype as the finished product. Thank you, goodbye." is a valid business choice though. Maybe the cost of the intern and the risk of being unable to effectively maintain or add features is worth it to the client. It's their choice if they would prefer it that way.

Re: Doing things the wrong way to get the right result

#33

Post by braveo »

lgunsch wrote: post #32
larrik wrote: post #7

The problem with this approach is when they say "okay, we'll have an intern do the manual keying each week and use the prototype as the finished product. Thank you, goodbye." Or the fact that it looks 90% done, so the idea that you did it in 2 weeks means you are just days away from completion, right? Sometimes the reasons for not hacking stuff together can be quite political, both for internal projects and for consu…

"okay, we'll have an intern do the manual keying each week and use the prototype as the finished product. Thank you, goodbye." is a valid business choice though. Maybe the cost of the intern and the risk of being unable to effectively maintain or add features is worth it to the client. It's their choice if they would prefer it that way.

Not only that, but the intern can make decisions that an automated system isn't going to be able to do safely due to ambiguities, etc.

This reminds me of an automated licensing call I was putting together once. The company owner wanted me to insert some verbiage into the notes field, only the web api didn't support the notes field (but you could do it by logging in and manually updating).

I had started to plan on how I was going to do this via a headless browser. I start asking the owner questions to clarify things and he says "just email XXX with the information and she'll manually log into the site and copy/paste the notes you put in the email".

And I thought... you know what? that's really fucking smart, I'm way overthinking this. They're going to get 4 or 5 license activations/month MAYBE and this approach is a whole hell of a lot more simple and robust than pulling in a headless browser to simulate it.

I then had to stop and think about why I hadn't considered that approach before.

I guess the point is that I agree with you wholeheartedly. Not only in terms of simply cost, but in terms of complexity, stability, and ambiguity as well.

Re: Doing things the wrong way to get the right result

#34

Post by braveo »

stinos wrote: post #17
concrete777 wrote: post #16

Earlier quoted context omitted.

Curious if you have some concrete examples of "loosely coupled" software projects. On GH perhaps? It's a concept I try to keep in mind, but am never sure I am "doing it right".

Mainly C++ dev here, I do think for example LLVM is very well done, and Boost as well. But both are immense codebases and especially Boost is complicated to the point it's insane. It's a shame but I don't have good examples of relatively small projects to check out. Maybe that's worth an 'Ask HN' thread: I've definitely seen threads like 'Ask HN: what are good open source projects to check' but without the extra requ…

I would point to both CLang and KDE as projects with very good modularity. I remember reading through the sources oc CLang a few years back and being impressed with it.

Re: Doing things the wrong way to get the right result

#35

Post by lscharen »

Being able to redefine the problem to get at a "quick and dirty" solution is absolutely a useful skill. What I think gets glossed over in the fine article and in some of the other comments, is that this is really only a good approach when one can also see the full solution as well and understands how to evolve past the "mechanical finger" if it becomes necessary to refine the system.

Where people get into trouble is when they have a short problem space horizon and don't have a decent feel for the trade-offs being made and a reasonable understanding of how the "wrong solution" is related to the "right solution". That can lead to the creation of a hack-y, fragile and unchangeable system that can really limit progress in the future.

Re: Doing things the wrong way to get the right result

#36

Post by zgryw »

lscharen wrote: post #35

Being able to redefine the problem to get at a "quick and dirty" solution is absolutely a useful skill. What I think gets glossed over in the fine article and in some of the other comments, is that this is really only a good approach when one can also see the full solution as well and understands how to evolve past the "mechanical finger" if it becomes necessary to refine the system. Where people get into trouble is…

Definitely.

If you know you're cutting corners, the ability to change in the future should be the priority. It usually means that you need to consider how the "perfect" solution would look like, so you know where the possible refinements will come to play.

Re: Doing things the wrong way to get the right result

#37

Post by aisofteng »

larrik wrote: post #7

The problem with this approach is when they say "okay, we'll have an intern do the manual keying each week and use the prototype as the finished product. Thank you, goodbye." Or the fact that it looks 90% done, so the idea that you did it in 2 weeks means you are just days away from completion, right? Sometimes the reasons for not hacking stuff together can be quite political, both for internal projects and for consu…

On my team, we tend to say that after finishing 90% of a project what remains is the other 90%.

Re: Doing things the wrong way to get the right result

#38

Post by dpflan »

Perhaps I am misunderstanding the discussion and do not see the "wrong" way: it seems that this consistent, incremental improvement is the "right way" to get to the the "right result". Isn't that very much a tenet of a whatever one may want to call a "lean start-up"

"""

We started with a completely unscalable solution, which enabled us to validate the need. We then evolved it, step by step, to make it support more and more users. On the way, we learned not only about our users, but also discovered what the technology requirements were. We can only speculate what the outcome of the project would have been if we hadn’t let ourselves find a “quick and dirty” solution.

"""

Re: Doing things the wrong way to get the right result

#39

Post by eksemplar »

hinkley wrote: post #22
eksemplar wrote: post #13

The coolest thing about ignoring trends is that most of them go away again. I pity the fool who did test first development on applications with less than 10 functionalities for instance. Even as a manager it's the gaffatape programmers who end up saving the day rather than the best practices. Obviously I won't advocate against following best practices. It's just that people never seem to agree on what they are, makin…

It's really hard to get gaffertape version 3.0 out the door. Those best practices are ultimately about reducing wear and tear on the development team, so you can keep momentum for a long long time. But since you can make pretty much any development strategy work for about 18 months, by the time the consequences are felt either those people are gone or nobody still there can paint a clear cause and effect story.

Which is the text book explanation, but you can gaffatape and still do SOLID, making everything easily replaceable later on.

The key feature of gaffatape programming is that it gets shit done, to make sure you're still around to do a 3.0 release.

The key downside of gaffatape is that it requires better talent, because your programmers need to know how to hack it in a way that won't ruin your codebase.

Re: Doing things the wrong way to get the right result

#40

Post by eksemplar »

marcosdumay wrote: post #30
eksemplar wrote: post #13

The coolest thing about ignoring trends is that most of them go away again. I pity the fool who did test first development on applications with less than 10 functionalities for instance. Even as a manager it's the gaffatape programmers who end up saving the day rather than the best practices. Obviously I won't advocate against following best practices. It's just that people never seem to agree on what they are, makin…

> Even as a manager it's the gaffatape programmers who end up saving the day rather than the best practices. Yes, the other ones are to busy fixing the gaffatape programmers' code to ensure the last day will stay saved.

I allcate more resources into fixing people who followed best practices wrongly, than I do into fixing what my gaffatape programmers made.

The thing about gaffatape programmers is that they learn how to do things that won't end up biting us in the ass later because they are thinking about what, why, and, how they are doing things by default, rather than following orders. Well some of them learn, the rest have short careers.

I mean, as I said, I don't advocate against best practices. If you want to gaffatapetape, you need to know best practices, because you need to understand why you are not following them.

Post reply on HN