Feb 7 2010

Retweet January 2010

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and/or juixe and I’ll be sure to follow back.

Software Development

  • If your code works not because of your programming intentions but because of bug side effects and your client doesn’t care, it is not done.
  • I need a software development bug repellent.
  • Design fail if you fix a log message and you break some functionality.
  • If a carpenter’s rule of thumb is to “measure twice, cut once” then a programmer’s rule of thumb should be “design twice, code once, refactor a few times, and optimize only if you have to.”
  • Saying you know programming is like saying you know how to read, a first grader knows how to read!!
  • Requirements gathering is not creative writing.
  • I love requirements: The initial instruction should completely initialize the initial value.

Team Leadership

  • The only two requirements for a manager is that he is breathing and that he can communicate with his team in their language.
  • What happens to you is not other people’s fault, it is your opportunity.
  • There is nothing worse than a perfectionist that doesn’t know what he wants.
  • The worst thing you can so when you make a mistake is lie about it.
  • Every once in a while you have to recalculate, reshuffle, and/or remix your priorities.
  • Embrace the edge.

Product Placement

  • In Google We Trust.
  • Google claims their motto is to ‘do no evil’, put I suggest they change it to ‘do no customer support.’
  • If you use Google search to find Google Mail customer support and still can’t find it, is that a fail in their customer support or search?
  • There should be Freedom of Information Act for corporations. I want to know everything that Google knows about me and how that info is used
  • Can’t believe the AT&T website is not iPhone/mobile friendly.
  • Apple should develop a dual screen iPhone, iPhone GS3 DS.
  • I imagine a time when Zynga will have in-game ads for Monsanto genetic modified seeds on FarmVille or Foster Farm turkeys for Cafe World.
  • Facebook saves everything you create/post/save/click/delete, it can reverse engineer what you where thinking.
  • Doing four square drive-by check-ins.
  • Does Craigslist have an iPhone app?
  • Do you have multiple twitter personality disorder?

Quote

  • If we let things terrify us, life will not be worth living. – Seneca
  • If I could make the same amount of money but wake up until when I can’t hold in my pee any longer, I will be a success. – Phil Kaplan
  • The answer to the question “where do good ideas come from” is always the same, the come from bad ideas. – Seth Godin
  • Only the mediocre are always at their best. – Jean Giraudoux
  • From pitch perspective, the more you wear your idea, the more it fits you… – Brad Feld
  • Nothing fails like success. – Arnold Toynbee
  • I totally question the conventional wisdom of the American dream. – Anil Dash
  • If we wait for the moment when everything, absolutely everything, is ready, we shall never begin. – Iva Turgenev

Dec 31 2009

Retweet 2009

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of tweets and rants from 2009. I started collecting and organizing programming related tweets into blogs posts early in the year. If you want to follow the conversation follow me at techknow and/or juixe and I’ll be sure to follow back.


Dec 19 2009

Juixe TechKnow Predictions 2010

Just like opinions, at the end of the year everyone has their own predictions for the new year. I came to these predictions by reading the back of caps of green tea bottles. If you like to see my accuracy with past predictions see the predictions of 2009.

  • In the future everybody will have their 15 minutes of fame and their own iPhone app on the App Store.
  • The App Store app review process will be even more stringent, opaque, and occult. the App Store will require a vial of blood from each iPhone developer.
  • Steve Jobs has himself cloned and a disk image of his memories will be implanted in the clone.
  • The Apple Tablet shall come with Steve Jobs’ iCommandments.
  • The Google Android platform will explode with hundreds of Android phones on the market, and no app review process for apps. Also the first Android trojan horse virus will affect Android users.
  • Google will release a Google Phone and become a true telephony company with Google Voice.
  • The Google Twins will have a falling out over an argument as to who does less evil.
  • Marissa Mayer, VP of Search Product and User Experience at Google, will leave Google for her own startup where she will develop the next killer web app which consists of a single search field and no buttons or text.
  • Twitter will be hacked, Fail Whale, and Jump the Shark all in the same day.
  • Facebook will buy Foursquare only to let it bit rot like Google did with Dodgeball.
  • Facebook will allow advertisers to impersonate you and post in your friends wall.
  • Zynga will but Facebook and rename it to FarmBook.
  • News Corp will buy Digg for $500 Million only to have all the users migrate over to Reddit.
  • Paul Graham will be deified by entrepreneurs around the world and will be given a mandatory 3% for $10 of all new startups.
  • The US government will award $10 million contract for an installation of WordPress for a government site.

Nov 7 2009

Retweet October 2009

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and/or juixe and I’ll be sure to follow back.

Software Development

  • I can haz codebyte!
  • Hacks are in the eye of the debugger.
  • Is there a werewolf in your software, then why do you need a silver bullet?
  • I know HACK is a four letter word but it is not a bad four letter word.
  • It is okay to paint by numbers but its something different to code by numbers. I code by polynomials.
  • If it doesn’t matter either way, why not choose the option that is easier to implement, cleaner to design, and friendlier to use.
  • Content is the killer app.
  • They say those who can’t do, teach. Well, those that can’t create content, aggregate.

Team Leadership

  • The sooner you adapt, the wider your lead.
  • Don’t nickel-and-dime old business assumptions.
  • When leading the way, be sure to get out of the way. As a leader you don’t want to be a roadblock or bottle neck to the troops.
  • A manager should do two things: give precise tasks and expect precise results.
  • Don’t confuse opinion for advice, don’t confuse advice for a plan.
  • Even a detailed schedule can’t predict the future.
  • Sometimes schedules are another way we lie to ourselves.
  • Time does not run on a schedule.
  • A good skill is to identify the skillset of your team, a better skill is to improve those skills while leveraging them to the fullest.
  • Little baby steps add up to giant leaps for mankind.

Product Placement

  • In Windows, when you overwrite a file instead of replacing it without a trace, the OS should put a copy in the recycle bin first.
  • You can learn a lot about someone by taking a look at their FarmVille farm.
  • Is Twitter lists just another metric for users to have a pissing match on Twitter? If comparing followers wasn’t enough…
  • Why is it that installing ImageMagick is a longer and more painful process than upgrading OSX?

Self Dev

  • In certain task I am worth my weight in gold, in others I am worth my weight in lead, but I do my best to avoid tasks were I cost my weight.
  • Many people will ask for out of the box ideas, but they don’t want ideas too far away from the box, more like ideas hovering around the box.
  • It’s okay to have your cake and eat it to, as long as you bake the cake yourself…
  • Be a double agent of change.
  • On man’s problem, is another man’s opportunity.
  • Authenticity has no substitute.
  • Not failing fast enough is the biggest failure.
  • Failure is when you don’t learn from it.
  • You have to kill it to win it.
  • Fail frequently, fast, and furious
  • If I played baseball I would be the GM.

Questions

  • What is the opposite of a trophy wife?
  • Do you have a failure resume?
  • Is Facebook to big to fail?
  • How many tweets does it take to get a trend?
  • There are wrinkle free pants, when will we see tangle free headphones?
  • Which is best Happily Ever After or Happily Ever Now?
  • What does it mean to ‘trust the chicken?’
  • Do you have to sell out to get buy in?
  • If you are not passionate, who do you expect your team to be passionate?

Quotes

  • Good ideas are simple. – @jason
  • Money is the shortcut. – @garyvee
  • Great entrepreneurs don’t have better ideas, they have better process. – Eric Ries
  • Pay attention to pixels. – Bump Technologies Job Listing

Sep 10 2009

World’s Most Famous Developer Excuse

I have to say that the World’s most commonly used excuse is “it works on my machine“. Amongst programmers this excuse must rank up there with other famous excuses like “It’s not you, it’s me” and “sorry, I guess I didn’t get reception.” When ever I hear a developer explain away broken builds, compilation errors, or bugs with “it works on my machine” I usually answer with one of the following replies, depending on my mood.

  • Oh, are going to ship your machine to the client.
  • Do you want all of us to work on your machine.
  • Yeah, so fix it on my machine!
You Break It, You Buy It

You Break It, You Buy It


Jul 22 2009

Don’t Turn a Code Review Into a Code Rant

In programming circles and when talking about code, I’ve often hear mentioned the Perl slogan “There’s more than one way to do it.” Thinking about the many ways we do it, whatever feature ‘it’ represents, I believe that the root cause of many of the software bugs we encounter are because engineers implement the feature in more than one way, then refactor it down the line, then add new conditions, then forgot how it did what it did. This often occurs because programming is like fashion, each season brings about a set of new best practices and technologies. We update the implementation to adapt to the current best practices, new technologies, and new features and don’t remove old bit rotten code.

Recently I a debate with a fellow engineer whose code I reviewed. As it is often the case, we had some existing functionality which we wanted to update with a feature. Most of the code review revolved around one existing method whose existing code looked something like the following.

public void setValue(DataRow dr) throws DataException {
  dataHelper.setValue(dr, false, true);
}

For the sake of this example, imagine that DataRow is a map of data that represents a row of data from a database and contains the meta-data of the columns it contains. The new functionality need to support a DataRow with a less number of meta-data, columns, than normally expected. We called this new feature partial value and so it was initially implemented as follows.

public void setValue(DataRow dr) throws DataException {
  dataHelper.setValue(dr, false, true);
}

public void setPartialValue(DataRow dr) throws DataException {
  setPartial(true);
  setValue(qube);
  setPartial(false);
}

Believe it or not, I had a very difficult and long drawnout debate with the engineer that implemented the above code. In my mind, there is no debate, the above code can be made to improve. In the engineer’s mind, this was good enough for this feature for the time allotted for the the current specifications for this release and for whatever other reason he counjured up.

One of the concerns I originally brought up with the initial implementation of setPartialValue was that if the setValue method throws an exception after having set the partial state to true, then the code will break out of both methods leaving an improper partial state behind. This will cause problems because the partial boolean field will have an invalid state which will caused problems if you the setValue method is called at a later point. Another problem, with this sort of style of programming, is the following scenario. Imagine that instead of a simple primitive boolean the partial property required an object reference that retained a lot of memory and you had the same exception, the memory for that field might not be garbage collected.

The sort of bugs that can be caused by the above implementation lead me to the following rule of thumb: Avoid instance fields. Always question the need for instance property. Try to be a team player and pass the object reference as a parameter down the stack. If you only need this little bit of state information for a method call, pass it as a parameter!

I couldn’t believe we had this much disagreement over three lines. At that moment I felt that code reviews are another form of micromanagement, but then I remembered who is the one that gets called if there is a bug in the system…. Yeah, me! The approach I was advocating did not require a object instance to keep the state of a boolean, which was only used within the context of the setPartialValue method call. In my approach the set/getPartial methods are not needed and it could have been refactored to the following.

public void setValue(DataRow dr) {
  setValue(dr, false);
}

private void setValue(DataRow dr, boolean partial) {
  dataHelper.setValue(dr, false, true, partial);
}

public void setPartialValue(DataRow dr) {
  setValue(dr, true);
}

The engineer countered that it “does not look nice” aesthetically to have a method call with to many parameters, and that we can’t just add parameters to methods whenever we need to pass another value. Touché. To this I responded that four parameters is not a big deal. Even though four parameter will not negatively affect a method signature, lets imagine that a method signature grew to 10 parameters, this can be solved by encapsulating all these parameters to one object. Programming languages such as Ruby use map literal for optional parameters and long parameter method signatures.

In the end, I won the debate but it didn’t feel like a victory. I doubted myself for pushing so strongly for what I know is right, in the end he was doing all the heavy lifting and this was just one small aspect of the feature as a whole. There is a line that if crossed you will be considered a micromanaging standard fascist, but that if you do not enforce you will inherit unmaintainable code. Coding standards goes beyond naming convention and third party libraries. There is a fine line, and you need to walk the line.