In addition, once you have hack solutions that are validated by users, replacing them with more robust solutions is extremely satisfying.
Nah. We just throw another hack on top of it.
If it works - don't fix it, usually wrongfully applies here.
Doing things the wrong way to get the right result
21–30 of 40 posts
Re: Doing things the wrong way to get the right result
#22The 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.
Re: Doing things the wrong way to get the right result
#23Thanks for including multi-megabyte pointless animated GIF. :|
Re: Doing things the wrong way to get the right result
#24The 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…
There is a bigger story about the project for "YayHappyFunTimesCorp" which included that difficult conversation - how to, instead of carrying on with designing new features quickly, slow down and make sure that everything that we hacked together is scalable. It's definitely not an easy one.
Re: Doing things the wrong way to get the right result
#25I encountered this in a personal project in the past week. The ideal, normalized schema would be slow and awkward for manual insertions on a daily basis, which I felt would deter me and hence undermine the project. The not-quite-normalized version would be much quicker and more intuitive for me to keep up-to-date, so I talked myself into it. In the future I can always write a stored proc to process the less-normalize…
It always helps to have someone to bounce those ideas off.
Re: Doing things the wrong way to get the right result
#26This idea is basically all about the future. If you don't have to worry about the future whatsoever, or have no business worrying about it (e.g. you're in a startup that might die in 6 months), by all means hack it together, get as far as you can, and "borrow" as much technical debt as you can rack up.
The longer the future of the project, the more likely that tech debt will have to be repaid. And the more closely you're involved with it, the more likely it's you who'll be paying it.
Re: Doing things the wrong way to get the right result
#27Earlier 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…
This may be a bit repetitive of me, but wondering if you can add some color around the phrase "higher level layers of the software".
Re: Doing things the wrong way to get the right result
#28I think this needs to be said to a lot of stubborn egotistical designers too. Ego in some ways is good but needs to be controlled and put aside so projects get the most effective outcome.
Absolutely. Same for designer, strategists, etc - however for some roles it's easier to "hack stuff together" than others.
I've seen designers simply copy and paste from an "inspirational" pinterest board, strategists copy and paste the first idea from an article or speech or book - hacking stuff together is for more than simply technical people.
Re: Doing things the wrong way to get the right result
#29I encountered this in a personal project in the past week. The ideal, normalized schema would be slow and awkward for manual insertions on a daily basis, which I felt would deter me and hence undermine the project. The not-quite-normalized version would be much quicker and more intuitive for me to keep up-to-date, so I talked myself into it. In the future I can always write a stored proc to process the less-normalize…
I took the exact opposite approach in a personal project. In my professional experience I have seen this exact same pattern with stored procedures use to hide poorly designed tables. After time, more entropy occurs in the system. Being able to change things comes to a crawl as you have duplicate data due to the initial poor schema design.
Many of the current databases like Postgresql let you create views. And the performance even on a smaller machine is quite good. So if you stick to a normalized schema and build views, it will pay dividends later on.
Re: Doing things the wrong way to get the right result
#30The 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.