Hacking the future

How to build a web site

In Uncategorized on December 10, 2009 at 6:20 am
  1. Web developers, product people, and customers brainstorm ideas.

    What problem are we trying to solve?
    What market opportunity are we trying to meet?

  2. Web developers & product people write the core user stories.
  3. Web developers build an end-to-end web site skeleton with mocks to any external systems.
  4. Web developers spec out the core web site API.
  5. Web developers and product people iterate over the web site skeleton adding the core user stories.
  6. Partnering with the customers web developers and product people push the product to market as quickly as possible.
  7. From customer feedback web developers and product people enhance, rewrite, or create new user stories and apply those stories back into the web site.
  8. Repeat 1-7

Meetings

In Uncategorized on December 9, 2009 at 5:05 am

It seems that in all my years of software development every company I work at seems to feel the need to pull people off of real work to have a meeting. Where they want to discuss some useless topic that just makes managers feel like the team is being productive by communicating status or issues. So what are good guidelines for meetings? Should we be having meetings? Here are my 3 golden rules:

  1. Meetings should never be scheduled; you should strive to create an environment where meetings just happen. How do you do this? Create open development environments where there are no offices or cubicles just groups of desks with lots of couches and whiteboards. In this environments meetings become organic and happen only when people need to talk.
  2. You should never have meetings to communicate status; that is why you use wiki’s and bug tracking tools. People who want status should just pull the status from those tools. It does not matter if you are standing up while you are giving status in a meeting or you call it agile. Status or issues should be an asynchronous activity where the people who need to know should be pulling those from the team, not slowing them down with a synchronous meeting.
  3. You should only have meetings for productive things like brainstorming new ideas, doing use cases, group design, discussing code, or getting the team together for drinking beer.

Erlang

In Uncategorized on September 11, 2009 at 2:27 am

I added another articles section for my other love language Erlang.

The first article is just a quick intro into this cool and powerful language, I will be sharing more soon..

http://carlosgabaldon.com/erlang/hello-erlang/