Moving On, Leaving Sogeti

Almost four years ago, I left working for Prudential Real Estate Services to go work as a consultant Sogeti. The intent was to surround myself with programmers in hopes that I could learn to become a better programmer myself. I’d like to say that the experiment was a success. I met some really great people, who taught me a great many things. It wasn’t all about the programming all the time, but I did get to work on tons of different projects, doing many different kinds of work.

But good things always have to come to an end at some point and a new beginning must be made. There are always new lessons to learn, new challenges to overcome, and cool new projects to get involved with. So as of today, I’m not longer employed by Sogeti, and will be moving on to a stealth-startup here in Houston.

Before you ask, no, this is not my startup, it’s someone elses. I’ll still be working on Just for Bands and a couple of other projects I have in the works (more on these soon, I hope). But this is a company that hired me to work with them on getting their product launched. Since I have a little bit of experience in that area, here’s hoping I can help them with theirs.

What will I be doing? At first it will mainly be Ruby on Rails work. But long term there is some mobile application development that will need to be done and I’m hoping I can get my feet wet in that area too. I’m the second developer on the ground, so there’s some room for growth as well. It promises to be an interesting project where I will get to apply some of the things I have recently learned about Ruby, Ruby on Rails, and getting an app from idea to launch. Hopefully I can learn a few things along the way as well.

Posted in General | Tagged , , | 2 Comments

Google, Android, and Open Source

Google announced that they would be holding back with regards to releasing the latest version of the Android operating system. The release in question, Android 3.0 aka Honeycomb aka the version for tablets. The reasoning for this they say is two fold: 1) the code isn’t ready to be released to the public, and 2) they don’t want manufacturers attempting to put Honeycomb on smaller form factor devices (read “mobile phones”).

Then Google announced yesterday that they were going to tighten the requirements on releasing Android based products. More specifically they were going to enforce the clause in their licensing agreement (the one that allows companies to use the “with Google” tag on their devices like the recently released Motorola Xoom) that the devices must meet certain standards and certain objectives must be met.

I want to look at both of these things in this article, because they kind of go hand in hand. Continue reading

Posted in Commentary, Technology | Tagged , , | Comments Off on Google, Android, and Open Source

Build Only What’s Necessary

When Erick and I set out to build LiveShow, we wrote down literally every idea that came to mind. No matter how outrageous, complex, forward thinking, backwards thinking, or idiotic, if it was an idea related to booking shows we wrote it down. When it came time to actually build the application, it became my job to keep us on the straight and narrow. Because as we worked on the application, more ideas came to mind.

Is it Absolutely Necessary

Eventually it all came down to one simple question: Is that feature/idea absolutely essential to booking a show for your band?

If the answer to that question was a “No” then we shelved the idea for possible later inclusion.  It might seem like a really weird idea to not build as many features as possible, but doing so keeps you on the path to actually launching your product.  If we hadn’t followed that one simple rule when deciding where to focus our work, Erick and I would still be working on LiveShow and wouldn’t have gotten it out the door.  If you don’t ever release your product/application then you can never make money off of it.

Release Early, Release Often

Creating an an application that runs and works on the internet means that you can release a product early and gradually add to its feature set as time passes.  The phrase is often heard in what is known as the “agile development method” and it’s called “Release early, release often” and it means to release the product at the earliest possible point and then gradually improve it over time (have many successive releases).

If you want an example of a company that does this frequently, look no further than Google.  A good example of Google doing this would be Gmail, their online email product.  When Gmail was first released it allowed you to do 2 things with the emails you got: read them or archive them.  There was no “delete” button because Gmail gave users one gigabyte of space, compared to Yahoo and Hotmail which gave around 250 megabytes of storage, that was a lot of space.  They believed you’d never need to delete an email again.  Over time they found that customers really wanted to be able to delete so they added a delete button, and then they add a “Trash” folder so you could recover accidentally deleted emails.  They also over time added Google Talk to Gmail.  And more recently they added the ability to make phone calls from within Gmail.  Gmail is just one example of Google doing this.  Android is another example, so is Google Calendar.

The idea is to get your product out in front of the public.  Even if it doesn’t have all the features you’d want it to have, if it at least accomplishes the basic goal of the application then it’s good enough to launch with.  Just because you launch it doesn’t mean it’s done.  You can still make changes, add features, and fix bugs.  Getting the product out in front of people allows you to figure out how people will use your application.  You might find that they use it in a way that you hadn’t foreseen and that might give you a whole new direction to go in (read about Flickr’s early beginnings for a good example of this).

Conclusion

When you start to build something, ask yourself what is the absolute essential things your product needs to allow users to achieve their goals.  If a feature or idea isn’t a part of that, then shelve it for later.  You want to get the product out to the public so they can use it, not keep it to yourself until it’s “perfect” because realistically it will never be perfect.  Get it out there.

Posted in General | Tagged , , | Comments Off on Build Only What’s Necessary

Build Only What's Necessary

When Erick and I set out to build LiveShow, we wrote down literally every idea that came to mind. No matter how outrageous, complex, forward thinking, backwards thinking, or idiotic, if it was an idea related to booking shows we wrote it down. When it came time to actually build the application, it became my job to keep us on the straight and narrow. Because as we worked on the application, more ideas came to mind.

Is it Absolutely Necessary

Eventually it all came down to one simple question: Is that feature/idea absolutely essential to booking a show for your band?

If the answer to that question was a “No” then we shelved the idea for possible later inclusion.  It might seem like a really weird idea to not build as many features as possible, but doing so keeps you on the path to actually launching your product.  If we hadn’t followed that one simple rule when deciding where to focus our work, Erick and I would still be working on LiveShow and wouldn’t have gotten it out the door.  If you don’t ever release your product/application then you can never make money off of it.

Release Early, Release Often

Creating an an application that runs and works on the internet means that you can release a product early and gradually add to its feature set as time passes.  The phrase is often heard in what is known as the “agile development method” and it’s called “Release early, release often” and it means to release the product at the earliest possible point and then gradually improve it over time (have many successive releases).

If you want an example of a company that does this frequently, look no further than Google.  A good example of Google doing this would be Gmail, their online email product.  When Gmail was first released it allowed you to do 2 things with the emails you got: read them or archive them.  There was no “delete” button because Gmail gave users one gigabyte of space, compared to Yahoo and Hotmail which gave around 250 megabytes of storage, that was a lot of space.  They believed you’d never need to delete an email again.  Over time they found that customers really wanted to be able to delete so they added a delete button, and then they add a “Trash” folder so you could recover accidentally deleted emails.  They also over time added Google Talk to Gmail.  And more recently they added the ability to make phone calls from within Gmail.  Gmail is just one example of Google doing this.  Android is another example, so is Google Calendar.

The idea is to get your product out in front of the public.  Even if it doesn’t have all the features you’d want it to have, if it at least accomplishes the basic goal of the application then it’s good enough to launch with.  Just because you launch it doesn’t mean it’s done.  You can still make changes, add features, and fix bugs.  Getting the product out in front of people allows you to figure out how people will use your application.  You might find that they use it in a way that you hadn’t foreseen and that might give you a whole new direction to go in (read about Flickr’s early beginnings for a good example of this).

Conclusion

When you start to build something, ask yourself what is the absolute essential things your product needs to allow users to achieve their goals.  If a feature or idea isn’t a part of that, then shelve it for later.  You want to get the product out to the public so they can use it, not keep it to yourself until it’s “perfect” because realistically it will never be perfect.  Get it out there.

Posted in General | Tagged , , | Comments Off on Build Only What's Necessary

Thinking of Starting a Web Business, You Can Do It

Do you say something like “Man it would be great is someone would create a site that does [fill in the blank]” a lot?  Do you find yourself coming up with great ideas only to forget them a couple of hours later?  Have you ever told an idea to your friends, have them tell you it’s horrible, only to see the exact product a year later released by someone else?

Well, do something about it.

Write Your Ideas Down

Have a great idea?  Write it down.  In a notebook, in Evernote (or SpringPad), on a napkin that you put in your pocket, write the idea down.  Basically store it somewhere that you won’t lose it later.  If you write the idea down, you can come back to it later.  I can’t tell you the number of ideas I let slip away because I had this great idea while I was at work and didn’t write it down.  So I started carrying a notebook (Amazon affiliate link) around.  When I have an idea, I stop and write it in my notebook on one of the pages dedicated to business ideas.  This allows me to easily find it later.  If I don’t have the notebook with me for some reason, I open up Evernote (web page or application) and write it down in a note that is specific to my business ideas.  Sure it means I have to look in two places when I’m reviewing those ideas, but at least I don’t forget the idea.

Don’t just write down the idea.  Write down anything related to it.  For example, I once had an idea to give companies the ability to create their own secure chat server, so I wrote the idea down, but I also wrote down to look at cloud computing options that would allow me to start and stop servers as needed, chat server software, protocols, and so on.  That way I just didn’t write down the idea but also the surrounding ideas so I knew what direction I wanted to go.

Pick An Idea

After you’ve gotten a few ideas written down, spend a Saturday reviewing them.  Flesh them out a little.  What do you need to implement those ideas?  What things should you research more?  Which one really gets you fired up?  If you find that an idea sparks a million other thoughts about that idea, go with it.  If you aren’t passionate about it, you’re probably not going to get very far with it.  However, if you find that a specific idea really gets your brain going, focus on it.  It’s really about passion.  You’re going to have to really like that idea to be able to spend the next year or so working on it.

Keep it Simple

That idea that’s spawning a million thoughts a second, that’s good.  But don’t let yourself get carried away with all those secondary ideas.  Write them down so you don’t lose them to the ether.  Instead, after you’ve written them down go ahead and pick the absolute essentials.  For every sub-idea, ask “is this absolutely essential to accomplishing the initial idea” and if the answer is “no” then move onto the next sub-idea.  This will help you determine what’s really important to the idea.  The ideas that aren’t absolutely essential can be worked on/implemented after launch.

This is important: If it’s not absolutely essential to the achieve the goal of your product, you don’t need it to launch.

Build It

This is one of the most important thing to do.  Build it.  Get working on it as soon as you can.  You’ll hit road blocks, have burn out, and have to put some time in during your off hours.  But if you don’t build it, you can’t release it.  Set up a schedule to work on the project.  A couple of hours a day, no less than three days a week.  Having such a schedule really helps you to set aside time for the project but still allow you to have a life.  Having a life outside of work and your side project will delay any burn out experience you’re likely to have.

When you do hit a period of burn out, work on something else related to the project.  Don’t have the website design, work on that.  Formulate plans for after the launch of the product.  Organize the to-do list or write a blog post about what you’re working on or some of the lessons learned so far.  These things help you get through the burn outs but allow you to maintain momentum and your work schedule.

Release It

This is probably the most important part of the whole process.  Getting it out to the public.  Letting real users hack away and break things.  Hey, thinks are going to break, accept this truth early on and you will be less stressed about it.  But releasing your product means you completed the process.  You took an idea from inception all the way to release.  Sure you probably hit some snags along the way.  It probably took you a little longer than you initially thought (it always does).  But, it’s released, it’s out there.

Unfortunately, just releasing the product isn’t enough.  You’ll need to make enhancements.  Those ideas I said you need to put to the side because they’re not essential, start cherry picking those and working on them.  You’ll have bugs to fix.  There will be customers to support, they’re going to request things.  Getting here though is the just the start of the journey.  If you can get to this point, you’ve made it farther than most.

Posted in General | Tagged , | 1 Comment

Vim, RubyTest, & RSpec

If you use the Vim editor (or one of it’s counterparts like gVim), use the RubyTest Vim Plugin, and you use RSpec for some of your testing then you might run into a problem that I was experiencing where it gives you the error:

[text]
:!echo ‘spec -f specdoc spec/greeter_spec.rb -l 8’ && spec -f specdoc spec/greeter_spec.rb -l 8
spec -f specdoc spec/greeter_spec.rb -l 8
/bin/bash: spec: command not found

shell returned 127
[/text]

Well, since I use RSpec 2.x (since I’m just now starting to use RSpec), the above error is quite annoying because the ‘spec’ command isn’t really used anymore (at least from what I can find on the internet).  So to get the RubyTest plugin to work with RSpec (and the ‘rspec’ command) you have to make a small change the plugin as marked below via a diff.

[diff]
— rubytest.vim.old 2011-01-29 14:29:19.897897990 -0600
+++ rubytest.vim 2011-01-29 14:30:16.487584334 -0600
@@ -21,10 +21,10 @@
let g:rubytest_cmd_testcase = "ruby %p -n ‘/%c/’"
endif
if !exists("g:rubytest_cmd_spec")
– let g:rubytest_cmd_spec = "spec -f specdoc %p"
+ let g:rubytest_cmd_spec = "rspec -f d %p"
endif
if !exists("g:rubytest_cmd_example")
– let g:rubytest_cmd_example = "spec -f specdoc %p -l %c"
+ let g:rubytest_cmd_example = "rspec -f d %p -l %c"
endif
if !exists("g:rubytest_cmd_feature")
let g:rubytest_cmd_feature = "cucumber %p"
[/diff]

Posted in programming | Tagged , , , , | Comments Off on Vim, RubyTest, & RSpec