Thursday, May 27, 2010

Started reading The Mythical Man-Month



Thought I'd share a cool passage from Dr. Brooks regarding creativity and the joy of development:

"First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful." [Brooks 1986]


This really resonates with me. I suppose it's what gets me out of bed each morning. There is something incredibly exciting about producing new and useful applications.

I've always said that creativity and godliness go hand in hand. Does that make me a megalomaniac? At times I do like to burn the midnight oil a bit too much. But damn it all if it isn't rewarding!

For instance: Take www.gogolingo.com. I allowed this project to wreck havoc on my life. During its production, I hardly slept, I barely socialized, I squeezed every last ounce of energy out my body and I loved it. For all my troubles, I have a shiny sparkling experience to share with the world and that's somehow worth what seemed like pain at the time.

I've gotten side tracked but the point should ring true. Dr. Brooks is spot on with his observation that creation is very rewarding.

Wednesday, May 26, 2010

The Scientific Method

It's funny how similar TDD is to the Scientific Method. In fact, I think that they're pretty much the same flow.


Scientific Method Flow:




TDD Flow:

Tuesday, May 25, 2010

The Art of Agile Development




I think I will always enjoy books put out by O'Reilly. The Art of Agile Development is no exception. This book was thought provoking and fun. The authors, of which there were two, tried many different ways of transferring their knowledge. I really respect their use of narrative style; it keeps you guessing (there is role playing be forewarned!). The book is a nice overview of agile philosophies (most heavily in favor of XP) and makes no claim that it is the de facto. They even go so far as to stress that you are invited to break the rules that the book lays out -- Explaining that an agile developer is one that asks the question why and that they will forever pursue mastery. I had a couple of "ah ha!" moments thanks to these guys (James Shore & Shane Warden). Thanks gents!

I have no intention of writing a full review but I will say that this is a great book for whetting your appetite for agile techniques. It's also filled with a wealth of references to further study.

They open up a section on Simple Design with:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupéry


Truly brilliant and a fantastic parallel to the topic! Love it!


I like the way they described TDD:

"Imagine TDD as a small, fast-spinning motor. It operates in a very short cycle that repeats over and over again. Every few minutes, this cycle ratchets your code forward a notch, providing code that -- although it may not be finished -- has been tested, designed, coded and is ready to check in."


If this sort of explanation is up your alley, then give the book a try, as it's what you can expect.

Lastly, I really appreciate that they pour in personal "in the trenches" examples. These help solidify the relevance of the various concepts.

Saturday, May 22, 2010

favicon.ico

Here's free online service that you can use to create .ico files

http://www.favicon.cc/

Friday, May 21, 2010

A test is NOT a Unit Test when...


  • It talks to a database

  • It communicates across a network

  • It touches the file system

  • You have to do special things to your environment (such as editing config files) to run it



Tests that do these things are integration tests, not unit tests. [Shore & Warden 2007]

Thursday, May 20, 2010

Google is giving away fonts

http://code.google.com/webfonts

I was about to save this link on delicious but then realized that it's useful to more than just myself and, therefore, please enjoy! It'll be interesting to see if Google actually nourishes the selection, as currently it's sparse at best. These fonts are widely supported by most browsers (so says Goog) but, remember, widely does not mean ubiquitously supported ;)

Typically, I use http://www.dafont.com/ for all my fancy typographical needs.

Wednesday, May 19, 2010

Unit Tests in PHP

Are you considering unit testing with your next PHP project?

Here's a xUnit family member:

http://www.phpunit.de/

Tuesday, May 18, 2010

Overview of Test-Driven Development

What is Test-Driven Development?

"Test-driven design (TDD) is a development technique where you must first write a test that fails before you write new functional code.[...]TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. - Ambler"


Scott Ambler has a thorough article on Test-Driven Development that explains the methodology. If you're curious on the subject, I recommend reading it:

http://www.agiledata.org/essays/tdd.html

Friday, May 14, 2010

Wasteful Multitasking

If you're in the camp that believe that the ability to multitask is a good thing then you're going to want to listen up. Plain and simple, it's less productive.

Because the brain cannot fully focus when multitasking, people take longer to complete tasks and are predisposed to error. When people attempt to complete many tasks at one time, “or [alternate] rapidly between them, errors go way up and it takes far longer—often double the time or more—to get the jobs done than if they were done sequentially,” states Meyer [3]. This is largely because “the brain is compelled to restart and refocus” [4]. A study by Meyer and David Kieras found that in the interim between each exchange, the brain makes no progress whatsoever. Therefore, multitasking people not only perform each task less suitably, but lose time in the process. [wikipedia]


For me, I multitask when I'm bored. Typically, I find myself losing interest in the task at hand so I jump to another task on my list. Then I feel guilty for orphaning what I had been working on so I'll jump back.

More Wikipedia you say? You got it!

When presented with much information, the brain is forced to pause and refocus continuously as one switches between tasks [4]. Realistically, this is “a rapid toggling among tasks rather than simultaneous processing.” According to a study done by Jordan Grafman, chief of the cognitive neuroscience section at the National Institute of Neurological Disorders and Stroke, “the most anterior part [of the brain] allows [a person] to leave something when it’s incomplete and return to the same place and continue from there,” while Broadman’s Area 10, a part of the brain’s frontal lobes, is important for establishing and attaining long term goals [3]. Focusing on multiple dissimilar tasks at once forces the brain to process all activity in its anterior. Though the brain is complex and can perform a myriad of tasks, it cannot multitask well. [wikipedia]



Last year there was an article in the Standford paper dealing with the topic of multitasking. As you could expect, the outlook was grim for those that boast about being able to - well you know.


http://news.stanford.edu/news/2009/august24/multitask-research-study-082409.html

"By doing less, you might accomplish more."


That's the final quote of the article. It's certainly true of agile development. We break production into manageable chunks and then we execute on them. If you find that you're jumping around too often, stop. It's not worth it. Perhaps it's time to engage in some Root-Cause Analysis to figure out what your motivation is for this disruptive habit.

I'll leave it at this. Here's an interview with the guy responsible for the Standford study.

Mind map & Flowchart Tools

Whenever I'm asked a question that I think may be useful for other people, I try and blog about it... Anyone new to project management will not be familiar with the tools of the trade for mind mapping or flowcharting so:

Are you in need of a flowchart? You've come to the right place. As you may know, I strongly oppose downloadable executables! Web 2.0 all the way baby! Sadly, I've yet to incorporate a 2.0 solution in my work flow.

That said, if you need to download and install something... The industry standard is Visio. Another valid solution is SmartDraw.

Here's a list of 2.0 solutions that I've yet to sample:

http://www.gliffy.com/
http://www.exploratree.org.uk/
http://www.lucidchart.com/
http://www.lovelycharts.com/
http://www.slickplan.com/
http://creately.com/
http://www.mindmeister.com/

I got that this from this guy.


I've also used www.bubbl.us to mind map. -- It was fun but buggy.

Happy charting!

Collective Code Ownership

We are all responsible for high quality code. There is a metric for imposed risk by concentrating knowledge in just a few people's heads -- it's called the truck number. How many people can get hit by a truck before the project suffers irreparable harm? [Shore & Warden 2007]


Some developers consider this job security and, if you're in a company or state of mind where this is your sentiment, I sympathize with you. But it shouldn't be the case!

I often tell my clients that I only hire people that love what they do. My belief is that if you love what you do then your exuberance will be infectious and thus pollute the groundwater. You simply spend too many hours of your life "working" so why be unhappy while doing it? Honestly, if you can't stand your job, then you need to take action. That said...

As a team, we can't operate at 100% efficiency when we do not have redundancy. Things come up... Folks get sick, have emergencies, retire, go on vacations, you get the picture. Your project should not suffer when a team member can't make the game.

The concept of Collective Code Ownership (CCO) extends to all areas of development. When only one developer knows how to tweak the installer, it's time to refactor or educate.

CCO also applies to bug fixes... I know that I personally don't enjoy rooting around through broken code, especially when it's not my own! However, it's different when you weave it into your company culture. I subscribe to the old boyscout motto: Try and leave this world better than you found it.

Ideally, we don't have bugs because we're using TDD. But, let's be honest, we don't live in an ideal world and mistakes happen. I know that some of you would accuse me of rose color glasses syndrome but I assure you that this is not just Utopian dribble. It really works. That said, if you spend more than 15 minutes digging around and can't find the problem, it's probably time to rollback to the last working build.

[With CCO] No one person can be the bottleneck for change. [extremeprogramming.org]


Collective code ownership requires letting go of a little bit of ego. Rather than taking pride in your code, take pride in your team's code. [Shore & Warden 2007]


CCO is a tool. If it doesn't work for you, don't use it. My vote, always evolve. Don't scoff at a good idea because you'll never know if you don't at least try.

Thursday, May 13, 2010

Need sound?

This resource is best suited for Flash games but can certainly work in a pinch for anything else. I've been thankful for them since 2005!

http://findsounds.com/

Walt Disney Quote

"Around here, however, we don't look backwards for very long. We keep moving forward, opening up new doors and doing new things, because we're curious...and curiosity keeps leading us down new paths." - Walt Disney

Wednesday, May 12, 2010

What does it mean to be done done?

If you ask the James Shore & Shane Warden, they'll tell you the following:


  • Tested (all unit, integration, & customer tests finished)

  • Coded (all code written)

  • Designed (code refactored to the team's satisfaction)

  • Integrated (the story works from end to end - typically, UI to database - and fits into the rest of the software)

  • Builds (the build scripts include any new modules)

  • Installs (the build script includes the story in the automated installer)

  • Migrates (the build script updated database schema if necessary; the installer migrates data when appropriate)

  • Reviewed (customers have reviewed the story and confirmed that it meets their expectations)

  • Fixed (all known bugs have been fixed or scheduled as their own stories)

  • Accepted (customers agree that the story is finished)


Can you run down this checklist at the close of an iteration and be certain that you've satisfied each bullet? If not, it's time to knock off a couple of the stories that you've committed to and focus on doing it right the first time.

Thursday, May 6, 2010

Thanks Google!

This is a really fun idea and absolutely cool of Google Labs!

http://jarlsberg.appspot.com/

Use of this app will no doubt make you a more conscientious programmer, experience is a fantastic teacher.

Never underestimate that a small group of thoughtful, committed people can change the world, indeed it's the only thing that ever has.

Never underestimate that a small group of thoughtful, committed people can change the world, indeed it's the only thing that ever has.
- Margaret Mead

Margaret didn't know it at the time but she was a huge advocate for Scrum!

Wednesday, May 5, 2010

We do not always know what we want deep down

Malcolm Gladwell is well known for his book the Tipping Point (which is a must read btw). Here's a TED talk that he spoke at on the subject of happiness.

Great quote:

"We do not always know what we want deep down." - Gladwell


Why is it the best quote? Because it's true! I can tell you that from conducting many formal and informal market research groups that consumers aren't a wealth of great ideas. However, this is not to say that such research is not useful. It's important to try new things. Experimentation breeds new products.

In his talk, Gladwell presses that diversity is important in product creation.

"...in embracing the diversity of human beings, we will find a sure way to true happiness." - Gladwell


Have a look for yourself. It's a fun watch :)

Tuesday, May 4, 2010

Met Jeff Sutherland



I got the chance to sit down with Dr. Jeff Sutherland last week. What an honor! It was at an event put on by Digital LA.

At the event, Jeff went over the basics of Scrum and some general insights.

Among his many pearls of wisdom - I enjoyed that he reminded us of the MIT slogan "Demo or Die". It's so important to show progress. Although apparently MIT changed that mantra to imagine and realise in the 90s.

It was perfect timing, as I gave my first lecture on Scrum that very weekend.

My lecture btw, went off without a hitch. I entitled it Scrum 101. Here's a look at the syllabus:

- A brief history of Scrum and its significance

- A functional understanding of the framework

- Basic instruction on implementing Scrum in your next small team project

I was able to cover my material in an hour and 15 minutes. However, I think I'll plan on a two hour timebox in the future. After the material was covered, we had a Q&A session that lasted for an additional hour.

About Me

I produce and engineer games and applications. | Portfolio | LinkedIn