Doing things the wrong way to get the right result
madebymany.com
Doing things the wrong way to get the right result
1–10 of 40 posts
Re: Doing things the wrong way to get the right result
#2I 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.
Re: Doing things the wrong way to get the right result
#3I always think this is very much the approach MVP (Minimum Viable Product) takes. I've seen this taken to the extreme in a company where the IT department where applying MVP to their internal business users creating absolute havock. Eventually Business Analysts were brought in to 'force' a more beneficial approach to delivering good solutions as well as get the business talking to IT in terms that each could understand.
There is a point within a company, where you have to switch from Minimum Viable Product to Minimum Valuable Product and try and live by the motto "Write your way out of a job".
Not sure where I am going with this, but I think the OP is right. We overthink things sometimes.
Re: Doing things the wrong way to get the right result
#4My first step would have been to search Amazon for a web enabled door buzzer.
Cool project though
Re: Doing things the wrong way to get the right result
#5This is often good advice especially in a startup, but it's not quite absolute. It's worth putting a certain amount of work into maintainability. It's worth pre-empting some classes of issues. And the further you shift into being a mature business, the more serious engineering becomes appropriate.
Re: Doing things the wrong way to get the right result
#6In addition, once you have hack solutions that are validated by users, replacing them with more robust solutions is extremely satisfying.
Re: Doing things the wrong way to get the right result
#7The 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 consultant/client relationships.
Re: Doing things the wrong way to get the right result
#8This is often good advice especially in a startup, but it's not quite absolute. It's worth putting a certain amount of work into maintainability. It's worth pre-empting some classes of issues. And the further you shift into being a mature business, the more serious engineering becomes appropriate.
Yes it's bit of a trade-off, as usual in software. Hacking can be the fastest now, but having worked on 10000loc code which consisted mainly of such hacks and none of the feasible maintainability: your hack might cause a ton of lost time in the future.
Then again, the more experienced you get, the easier it will be to spot if a hack is the appropriate thing or not. Like if your software is already nicely established and loosely coupled you can apply hacks here and there without any negative effect on maintainability or functionality whatsoever.
Re: Doing things the wrong way to get the right result
#9I 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-normalized data into idealized tables, and use the original tables solely for importing the data.
Despite that reassurance it was remarkably difficult to accept that doing the 'wrong thing' programmatically was the 'right thing' in a project scope.
Re: Doing things the wrong way to get the right result
#10I 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.