Skip to main content

Joel Liu's Library tagged development →  View Popular, Search in Google

Aug
28
2010

  • I remember reading a paper a long time ago about traffic engineering. It turns out that when there's a traffic problem you have three choices more or less:

    1) Add something

    2) Change something

    3) Remove something

    The paper talked about how most civil engineers have a strong bias toward 1, followed by 2, and then rarely 3. The first thought is almost always to add something. Something is wrong? That means we need something more to solve it, right?

    Complexity is not a virtue. It's actually a vice and a liability. It is better to solve a problem by removing something than by adding something. This (along with losing sight of what customers want) is the problem with engineer-driven design. Engineers like to add stuff, not remove stuff.

    Wave always looked horridly over-complex to me. The protocol was a tower of babel. It was "open," but it was so complex that nobody would bother climbing its learning curve. It tried to solve too many problems at once, it was slow, and it was cumbersome to use. Those are all signs of over-engineering.

  • Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
  • 2 more annotation(s)...
Aug
26
2010

  • Steps 1-3 and 5-6 are "easy", but how do you step 4?

    4. Seek expert feedback, in intermittent doses

    It would be great if my company did code reviews on everything a la Google, but that’s not going to happen any time soon. I code in my spare time, but what expert is going to want to check out my spare time projects, project euler solutions, or what have you, and give feedback? So, how do I go about getting expert feedback?

  • Join an open source project? Find someone at work that's willing to do reviews for you if you do them for him? (slow-motion pair programming, kind of). Read code written by your company's best programmers and compare what they did with how you would have done it?
Aug
25
2010

  • SCRUM ... all irrelevant unless the software we're building meets the needs of those that are using it.

    That statement misses the entire point of Scrum. What are those short iterations for, if not to get feedback from those using the software? Why replan at the end of every sprint, if not to know how user needs have changed and been informed by the current software?

    How is the readme so different from the sprint's user stories? Working from the desired end docs looks like another version of the currently fashionable "pull" methods. Not a bad one for a particular kind of project though.

  • A perfect implementation of the wrong specification is worthless. By the same principle a beautifully crafted library with no documentation is also damn near worthless. If your software solves the wrong problem or nobody can figure out how to use it, there's something very bad going on.
  • Most importantly, you're giving yourself a chance to think through the project without the overhead of having to change code every time you change your mind about how something should be organized or what should be included in the Public API. Remember that feeling when you first started writing automated code tests and realized that you caught all kinds of errors that would have otherwise snuck into your codebase? That's the exact same feeling you'll have if you write the Readme for your project before you write the actual code.
  • 1 more annotation(s)...
Jul
23
2010

    • Over the next few months, we are going to be rolling out a new release process to accelerate the pace at which Google Chrome stable releases become available. Running under ideal conditions, we will be looking to release a new stable version about once every six weeks, roughly twice as often as we do today.

      So why the change? We have three fundamental goals in reducing the cycle time:
      • Shorten the release cycle and still get great features in front of users when they are ready
      • Make the schedule more predictable and easier to scope
      • Reduce the pressure on engineering to “make” a release
    • So why the change? We have three fundamental goals in reducing the cycle time:
      • Shorten the release cycle and still get great features in front of users when they are ready
      • Make the schedule more predictable and easier to scope
      • Reduce the pressure on engineering to “make” a release
      The first goal is fairly straightforward, given our pace of development. We have new features coming out all the time and do not want users to have to wait months before they can use them. While pace is important to us, we are all committed to maintaining high quality releases — if a feature is not ready, it will not ship in a stable release.
  • 2 more annotation(s)...
Jul
18
2010

  • I took a look at a few of the apps, and many of them contain plenty of clunky programming leading to severe performance inefficiencies (read: battery life inefficiencies) that could lead to very bad habits being picked up by a fledgling, but I still consider this resource a pretty good starting point. Don't forget to update the Base SDK setting before playing around with the projects, as the sources are a bit out-of-date and won't properly compile against newer SDKs.
1 - 20 of 60 Next › Last »
Showing 20▼ items per page

Selected Tags

Related Tags

Diigo is about better ways to research, share and collaborate on information. Learn more »

Join Diigo
Move to top