I believe there are two separate concepts here: quickness and simplicity. I would agree that simplicity makes the system easier to fully understand, thus making it easier (and usually quicker!) to change later. However, I believe that simplicity is hard and is generally not the quickest solution.
That being said, the quickest solution now does not necessarily make the code quicker to change later: there are trade-offs with every solution. --- My highlight from this talk is the concept of an explicit problem-solving strategy to better facilitate these discussions, e.g. what are the requirements? what are the trade-offs of a solution?: spending the extra time to build a simple, easy-to-change system is not worthwhile if it will get thrown out next week! :) I want to emphasize that it’s important to adapt any strategy to your own needs – as Margaret mentions, it’s often hard to fully understand a problem before writing some code and I agree for myself. On the other hand, for the presenter, it seems viable to not write any code at all! It’s been valuable to take a step back to understand how I think. By doing so, I can try to optimize the process I need in order to come up with the most-reasonable solution – the one with appropriate trade-offs for a given situation. - Mike On Wed, Apr 20, 2016 at 4:56 AM, Margaret Leibovic <mleibo...@mozilla.com> wrote: > My one word of caution here is that it's often hard to fully understand a > problem before you roll up your sleeves and start writing some code. IMO, > the quickest way to come up with a solution is often to come up with a > wrong solution first, then throw it away. Similar to how we build > prototypes to come up with product/ux solutions. > > In my experience, the longer I spend thinking about a problem before I > take any action, the more paralyzed I become. Code is never perfect, it's > always going to need to change. Sure, try to minimize the amount of > fundamental changes you're going to need to make, but in the end I think > simplicity is your best bet against future pain. > > Margaret > > On Tue, Apr 19, 2016 at 8:05 PM, Richard Newman <rnew...@mozilla.com> > wrote: > >> This is Rich Hickey, the creator of Clojure, which is right up there as >> one of the best-thought-through pieces of software I've ever seen. >> >> If you haven't read through Clojure's approach to managing mutable state, >> it's worth the time. >> >> http://clojure.org/about/state >> >> and also its particular set of tradeoffs, particularly being a JVM-hosted >> language: >> >> http://clojure.org/about/rationale >> >> >> >> On Tue, Apr 19, 2016 at 4:44 PM, Michael Comella < >> michael.l.come...@gmail.com> wrote: >> >>> Hey friends! >>> >>> Today, I sent Sebastian a talk that's made me rethink my development >>> style and I realized I should open it up to a wider audience: >>> >>> https://www.youtube.com/watch?v=f84n5oFoZBc >>> >>> Note: it's development-centric, but not development-specific. >>> >>> The presenter provides an explicit problem solving strategy to take when >>> solving hard problems and provides some important questions to ask – e.g. >>> what are the facts surrounding the problem? What are the constraints? What >>> don't you know yet? Even if you disagree with the approach of the >>> presenter, I think it's beneficial to have an explicit problem-solving >>> strategy. >>> >>> In this or another talk, the presenter mentions that he feels many bugs >>> come from having a poor-conception of the problem. After applying an >>> explicit strategy to problem solving, it's been insightful to have a better >>> concept of what I'm building before I start trying to build it and >>> (granted, it's still with a small sample size) I feel it's produced better >>> code with fewer bugs. >>> >>> Here are some notes on the talk [1] but it's unclear how helpful they >>> are without watching the video. Personally, I've copied this document, >>> simplified it, and have been adapting it for what approach what works for >>> me. >>> >>> Enjoy! >>> - Mike (:mcomella) >>> >>> [1]: http://willchen.me/hammock-driven-development >>> >>> _______________________________________________ >>> mobile-firefox-dev mailing list >>> mobile-firefox-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>> >>> >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> mobile-firefox-dev@mozilla.org >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> >> >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
