The Devver Blog

A Boulder startup improving the way developers work.

Archive for the ‘Misc’ Category

Playing with Processing, Making Snow

What is Processing?

“Processing is an open source programming language and environment for people who want to program images, animation, and interactions.”
Processing.org

I wanted to play around with doing some visual programming and had played with Processing in the past. I recently had been reading about Ruby-Processing and wanted to give it a shot. First, I went to look for some Ruby-Processing tutorials, and I had recently heard about the presentation by Jeff Casimir about the ‘Art of Code‘ (slides and code), using Ruby-Processing. I went through those examples and decided I wanted to modify it to display snowflakes in the spirit of winter. After a bit of searching I found a project that generated a Penrose snow flake using Ruby-Processing. I figured I could modify the programs to get a nice snow flake screen saver type app. The result is my app Processing-Snow, and is shown in the screen shot below.

Processing-Snow

Playing around with Ruby-Processing is a lot of fun, I highly recommend spending a couple hours to make a tiny app. I built my Snow app in about an hour and a half. Then I spent a bit of time using Caliper to improve the metrics. For such a small project there wasn’t a lot to improve, but it still helped me to do some refactoring. To get an idea of the code you can view Processing-Snow’s Metrics.

Feel free to fork Processing-Snow on GitHub and read about how to run it with in the projectss README.

Written by DanM

December 23, 2009 at 8:16 pm

Posted in Hacking, Misc, Ruby

Improving Code using Metric_fu

Often, when people see code metrics they think, “that is interesting, I don’t know what to do with it.” I think metrics are great, but when you can really use them to improve your project’s code, that makes them even more valuable. metric_fu provides a bunch of great metric information, which can be very useful. But if you don’t know what parts of it are actionable it’s merely interesting instead of useful.

One thing when looking at code metrics to keep in mind is that a single metric may not be as interesting. If you look at a metric trends over time it might help give you more meaningful information. Showing this trending information is one of our goals with Caliper. Metrics can be your friend watching over the project and like having a second set of eyes on how the code is progressing, alerting you to problem areas before they get out of control. Working with code over time, it can be hard to keep everything in your head (I know I can’t). As the size of the code base increases it can be difficult to keep track of all the places where duplication or complexity is building up in the code. Addressing the problem areas as they are revealed by code metrics can keep them from getting out of hand, making future additions to the code easier.

I want to show how metrics can drive changes and improve the code base by working on a real project. I figured there was no better place to look than pointing metric_fu at our own devver.net website source and fixing up some of the most notable problem areas. We have had our backend code under metric_fu for awhile, but hadn’t been following the metrics on our Merb code. This, along with some spiked features that ended up turning into Caliper, led to some areas getting a little out of control.

Flay Score before cleanup

When going through metric_fu the first thing I wanted to start to work on was making the code a bit more DRY. The team and I were starting to notice a bit more duplication in the code than we liked. I brought up the Flay results for code duplication and found that four databases models shared some of the same methods.

Flay highlighted the duplication. Since we are planning on making some changes to how we handle timestamps soon, it seemed like a good place to start cleaning up. Below are the methods that existed in all four models. A third method ‘update_time’ existed in two of the four models.

 def self.pad_num(number, max_digits = 15)
    "%%0%di" % max_digits % number.to_i
  end

  def get_time
      Time.at(self.time.to_i)
  end

Nearly all of our DB tables store time in a way that can be sorted with SimpleDB queries. We wanted to change our time to be stored as UTC in the ISO 8601 format. Before changing to the ISO format, it was easy to pull these methods into a helper module and include it in all the database models.

module TimeHelper

  module ClassMethods
    def pad_num(number, max_digits = 15)
      "%%0%di" % max_digits % number.to_i
    end
  end

  def get_time
      Time.at(self.time.to_i)
  end

  def update_time
    self.time = self.class.pad_num(Time.now.to_i)
  end

end

Besides reducing the duplication across the DB models, it also made it much easier to include another time method update_time, which was in two of the DB models. This consolidated all the DB time logic into one file, so changing the time format to UTC ISO 8601 will be a snap. While this is a trivial example of a obvious refactoring it is easy to see how helper methods can often end up duplicated across classes. Flay can come in really handy at pointing out duplication that over time that can occur.

Flog gives a score showing how complex the measured code is. The higher the score the greater the complexity. The more complex code is the harder it is to read and it likely contains higher defect density. After removing some duplication from the DB models I found our worst database model based on Flog scores was our MetricsData model. It included an incredibly bad high flog score of 149 for a single method.

File Total score Methods Average score Highest score
/lib/sdb/metrics_data.rb 327 12 27 149

The method in question was extract_data_from_yaml, and after a little refactoring it was easy to make extract_data_from_yaml drop from a score of 149 to a series of smaller methods with the largest score being extract_flog_data! (33.6). The method was doing too much work and was frequently being changed. The method was extracting the data from 6 different metric tools and creating summary of the data.

The method went from a sprawling 42 lines of code to a cleaner and smaller method of 10 lines and a collection of helper methods that look something like the below code:

  def self.extract_data_from_yaml(yml_metrics_data)
    metrics_data = Hash.new {|hash, key| hash[key] = {}}
    extract_flog_data!(metrics_data, yml_metrics_data)
    extract_flay_data!(metrics_data, yml_metrics_data)
    extract_reek_data!(metrics_data, yml_metrics_data)
    extract_roodi_data!(metrics_data, yml_metrics_data)
    extract_saikuro_data!(metrics_data, yml_metrics_data)
    extract_churn_data!(metrics_data, yml_metrics_data)
    metrics_data
  end

  def self.extract_flog_data!(metrics_data, yml_metrics_data)
    metrics_data[:flog][:description] = 'measures code complexity'
    metrics_data[:flog]["average method score"] = Devver::Maybe(yml_metrics_data)[:flog][:average].value(N_A)
    metrics_data[:flog]["total score"]   = Devver::Maybe(yml_metrics_data)[:flog][:total].value(N_A)
    metrics_data[:flog]["worst file"] = Devver::Maybe(yml_metrics_data)[:flog][:pages].first[:path].fmap {|x| Pathname.new(x)}.value(N_A)
  end

Churn gives you an idea of files that might be in need of a refactoring. Often if a file is changing a lot it means that the code is doing too much, and would be more stable and reliable if broken up into smaller components. Looking through our churn results, it looks like we might need another layout to accommodate some of the different styles on the site. Another thing that jumps out is that both the TestStats and Caliper controller have fairly high churn. The Caliper controller has been growing fairly large as it has been doing double duty for user facing features and admin features, which should be split up. TestStats is admin controller code that also has been growing in size and should be split up into more isolated cases.

churn results

Churn gave me an idea of where might be worth focusing my effort. Diving in to the other metrics made it clear that the Caliper controller needed some attention.

The Flog, Reek, and Roodi Scores for Caliper Controller:

File Total score Methods Average score Highest score
/app/controllers/caliper.rb 214 14 15 42

reek before cleanup

Roodi Report
app/controllers/caliper.rb:34 - Method name "index" has a cyclomatic complexity is 14.  It should be 8 or less.
app/controllers/caliper.rb:38 - Rescue block should not be empty.
app/controllers/caliper.rb:51 - Rescue block should not be empty.
app/controllers/caliper.rb:77 - Rescue block should not be empty.
app/controllers/caliper.rb:113 - Rescue block should not be empty.
app/controllers/caliper.rb:149 - Rescue block should not be empty.
app/controllers/caliper.rb:34 - Method name "index" has 36 lines.  It should have 20 or less.

Found 7 errors.

Roodi and Reek both tell you about design and readability problems in your code. The screenshot of our Reek ‘code smells’ in the Caliper controller should show how it had gotten out of hand. The code smells filled an entire browser page! Roodi similarly had many complaints about the Caliper controller. Flog was also showing the file was getting a bit more complex than it should be. After picking off some of the worst Roodi and Reek complaints and splitting up methods with high Flog scores, the code had become easily readable and understandable at a glance. In fact I nearly cut the Reek complaints in half for the controller.

Reek after cleanup

Refactoring one controller, which had been quickly hacked together and growing out of control, brought it from a dizzying 203 LOC to 138 LOC. The metrics drove me to refactor long methods (52 LOC => 3 methods the largest being 23 LOC), rename unclear variable names (s => stat, p => project), move some helpers methods out of the controller into the helper class where they belong. Yes, all these refactorings and good code designs can be done without metrics, but it can be easy to overlook bad code smells when they start small, metrics can give you an early warning that a section of code is becoming unmanageable and likely prone to higher defect rates. The smaller file was a huge improvement in terms of cyclomatic complexity, LOC, code duplication, and more importantly, readability.

Obviously I think code metrics are cool, and that your projects can be improved by paying attention to them as part of the development lifecycle. I wrote about metric_fu so that anyone can try these metrics out on their projects. I think metric_fu is awesome, and my interest in Ruby tools is part of what drove us to build Caliper, which is really the easiest way try out metrics for your project. Currently, you can think of it as hosted metric_fu, but we are hoping to go even further and make the metrics clearly actionable to users.

In the end, yep, this is a bit of a plug for a product I helped build, but it is really because I think code metrics can be a great tool to help anyone with their development. So submit your repo in and give Caliper hosted Ruby metrics a shot. We are trying to make metrics more actionable and useful for all Ruby developers out, so we would love to here from you with any ideas about how to improve Caliper, please contact us.

Written by DanM

October 27, 2009 at 10:30 pm

Lone Star Ruby Conf 2009 Wrapup Review

I recently went to the Lone Star Ruby Conference (LSRC), in Austin TX. It was great to be able to put faces to many people I had interacted with in the Ruby community via blogs and twitter. I also got to meet Matz and briefly talk with him, which was cool. Meeting someone who created a language which is such a large part of your day to day life is just an interesting experience. I enjoyed LSRC, and just wanted to give a quick summary of some of the talks that I saw and enjoyed. This is by no means full coverage of the event, but hopefully sharing my experience with others is worth something. If you are interested in seeing any of the talks keep an eye out for Confreaks, they taped the event and many of the talks should be coming online soon.

Dave Thomas
Dave was the first speaker for LSRC, and it was a great way to kick off the event. Dave gave a talk about Ruby not being perfect and that is why he likes it. I have heard Dave speak before, and I always enjoy his talks. It isn’t like you learn anything specific about Ruby development, but you learn about the Ruby community. Actually, Dave would say we are a collection of Ruby communities, and that having a collection of communities is a good thing. It was also interesting to hear Dave speak about the entire Zed, “Rails is a Ghetto” incident. Sometimes when you are angrily ranting around online, it is easy to forget that there are real people attached to things. Feelings can get hurt, and while Dave agrees there is some valid points in the post, I think it shows that it probably isn’t a good way to go about fixing them. Dave really loves Ruby and the weird things you can do with the language and it shows.

Glenn Vanderburg, Programming Intuition
Glenn talked about phyical emotions tied to code, such as a sense of touch or smell. The talk generally just evoked memories of Paul Graham’s “Hackers and Painters” in my head, in fact Glenn talked about PG during his talk. The best programmers talk about code as if they can see it. The talk explored ways to feel the code and react to it. It tried to promote the idea that it is OK to just have a gut reaction that some code is a bad way to do things, because we should sense the code. Glenn also played a video showing Bobby McFerrin teaching the audience the Pentatonic scale, which I really enjoyed.

James Edward Gray II, Module Magic
James visited Japan recently and went to a Ruby conference, and he really enjoyed it. About half his talk was why Japan is awesome… He then found little ways to tie this back into his talk about Ruby and Modules. It covered some interesting topics like load order that many people just don’t know enough about, but use every day. Examples of the differences between include and extend. Modules are terrific at limiting scope, limit the scope of scary magic and keep it hidden away. I enjoyed talking with James a good amount through out the conference. I had never met him before LSRC, but I used to practice Ruby working on Ruby Quiz which he ran for a long time.

James has his slides are up, Module Magic

Fernand Galiana, R-House
Fernand gave a really cool and demo heavy talk about home automation. He has a web front end that lets him interact with all his technology. His house tweets most of the events that it runs. The web interface has a iPhone front in, so he can, on the go, change the temperature or turn off lights. I have always been a real home automation geek. When I was growing up, my dad loved playing with an X-10 system that we had in the house. I am really interested in playing with some of this stuff when I have my own place, mostly looking at ways I could use it to cut waste on my energy usage.

Mike Subelsky, Ruby for Startups: Battle Scars and Lessons Learned
* You Ain’t Gonna Need It (YAGNI), don’t worry about being super scaling at the beginning…
* Early days focus on learning more data about what your building and what your customers want concentrate on the first 80% solution.
* Don’t over build, over design, or over engineer.
* Eventually plan to move everything out of your web request, build it so that it will be easy to do in the future, but it isn’t worth doing at first. (delayed job, EM, etc)
* Make careful use of concurrency, prefer processes communicating via messages (SQS etc…) If you are doing threading in your software EM is your friend.
* Avoid touching your RDBMS when you are storing not critical data:
– Storing large text blogs in S3, message across SQS, tons of logging SDB
* Don’t test all the time at the beginning, it gets in the way of exploration… Things that is mission critical maybe should be BDD as it will be the most stable and least likely to change part of your code

Mike posted his slides on his blog, Ruby for Startups.

Jeremy Hinegardner, Playing nice with others. — Tools for mixed language environments

Jeremy wanted to show how easy it is to use some code to make it easy to work with a system that uses multiple languages. He brought up that most projects in the room utilize more than one language. That it will be more common as systems grow in complexity. He looked at a lot of queues, key value stores, and cache-like layers that can be talked to by a variety of language. He then showed some code that would quickly demonstrate how easy it was to work with some of these tools. Extra points because he talked about Beanstalkd, which I personally think is really cool. I think nearly everyone is starting to look at work queues, messaging systems, and non standard databases for their project and this was a good overview of options that are out there.

Yukihiro Matsumoto (Matz), Keynote and Q&A
Matz gave a talk about why we, as a community, love Ruby. In this talk there weren’t really any takeaways that were specifically about Ruby code but more about the community and why Ruby is fun. He spent a good amount of time talking about Quality Without A Name, QWAN. More interesting than the talk was the Q&A session. I thought the most interesting question was why Ruby isn’t on Git yet. He said the teams doesn’t have time to convert all the tools they use from SVN to git. He also mentioned that the git project tracking SVN is very close to the SVN master and is a good way to work on the Ruby code.

Evan Light, TDD: More than just “testing”
Evan first covered that the tools we as a community keep getting excited about aren’t really what matters. What matters is TDD technique. After discussing why tools aren’t as important for awhile, Evan began live coding with the audience. Something I thought was pretty impressive as it would be difficult to do. It made for a weird pair programming exercise with the entire audience trying to drive. Which sometimes worked well and sometimes lead to conflicting ideas / discussion (which made for interesting debate). It was over all a really interesting session, but it is hard to pull out specific tidbits of wisdom from the talk.

Jake Scruggs, What’s the Right Level of Testing?
I have known of Jake for awhile from his work on the excellent Metric Fu gem. Jake explored what the right level of testing for a project is, from his experience on his last nine projects over the years. He explored what worked, what didn’t and what sometimes works but only depending on the people and the project. I think it comes to this conclusion: what works for one project won’t work for all projects. Having some testing and getting the team on a similar testing goal will make things much better. He also stressed the importance of metrics along with testing (really? From the metric-fu guy? Haha). If testing is old and broken, causing team backlash, low morale, and gridlock, it might be better to lessen the testing burden or throw away difficult to maintain tests. Getting rid of them and getting them out of the way, might be worth more than the value the tests were providing. In general he isn’t big into view testing, he likes to avoid slow testing. He likes to have a small ‘smoke screen’ of integration tests, to help verify the system is all working together. In the end, what is the right level of testing for a project? The answer: what level of assurance does the given project really need? In a start-up you probably don’t need a huge level of assurance, speed matters and market feedback matter more. If your building parts for a rocket or medical devices it is entirely different.

I enjoyed this talk quite a bit, and it inspired me to fix our broken metric_fu setup and start tracking on projects metrics again. Jake also wrote a good roundup of LSRC

Corey Donohoe @atmos, think simple
Corey gave interesting quick little thoughts and ideas about how to stay productive, happy, learn more, do more, fail less, and keep things simple and interesting… Honestly with something like 120+ slides, I can’t even begin to summarize this talk. I checked around and couldn’t find his slides online, but they couldn’t really do the talk justice anyways. Keep your eyes peeled for the video as it was a fun talk, which I enjoyed. Until then here is a post he made about heading to LSRC.

Joseph Wilk, Outside-in development with Cucumber
Cucumber is something I keep hearing and reading about, but haven’t really gotten a chance to play with it myself. Joseph’s talk was a good split between a quick intro to Cucumber, and diving in deeper to actually show testing examples and how it worked. From the talk it sounded to me like Cucumber was mostly a DSL to talk between the customer and the developer/tester. I don’t know if that is how others would describe it. I thought Cucumber was an odd mix of English and and Ruby, but it helps effectively tell a story. Since returning form LSRC, I have started working on my first Cucumber test.

Yehuda Katz, Bundler
This was just a lightening talk about Bundler, which I had read about briefly online. Seeing the work that was done for this blew me away. I can honestly say I hope this takes over the Ruby world. We have been dealing with so many problems related to gems at Devver, and if Bundler becomes a standard, it would make the Ruby community a better place. I am really excited about this so go check out the Bundler project now.

Rich Kilmer, Encoding Domains
The final keynote of the event was about encoding domains. I didn’t really know what to expect going into this talk, but I was happily surprised. Rich talked about really encapsulating a domain in Ruby and then being able to make the entire programming logic much simpler. He gave compelling examples of working with knowledge workers in the field and just writing code with them to express their domain of knowledge in Ruby code. Live coding with the domain with experts he jokingly called “syntax driven development” – you write code with them until it doesn’t raise syntax errors. Rich spoke energetically and keep a tiring audience paying attention to his stories about projects he has worked on through out the years. Just hearing about people who have created successful projects who have been working with Ruby in the industry this long is interesting. I thought it had great little pieces of knowledge that were shared during the talk, but again this was a talk where it was to hard to pull out tiny bits of information, so I recommend looking for the video when it is released.

Final Thoughts
LSRC was a good time besides hearing all the speakers. In fact like most conferences some of the best knowledge sharing happened during breaks, at dinner, and in the evenings. It also gave me a chance to get to know some of the community better than just faceless Twitter avatars. It was fun to talk with Ruby people about things that had nothing to do with Ruby. I also am interested in possibly living in Austin at some point in my life so it was great to check it out a bit. Friday night after the conference I went out with a large group of Rubyists to Ruby’s BBQ, which was delicious. We ate outside with good food, good conversation, and live music playing next door. As we were leaving someone pointed out that the guitarist playing next door was Jimmy Vaughn, brother of the even more famous Stevie Ray Vaughan. We went over to listen to the show and have a beer, which quickly changed into political speeches and cheers. Suddenly I realized we were at a libertarian political rally. I never expected to end up at a Texan political rally with a bunch of Rubyists, but I had a good time.

Hopefully the next Ruby conference I attend with be as enjoyable as LSRC was, congrats to everyone who helped put the conference together and all those that attended the event and made it worth while.

Written by DanM

September 3, 2009 at 3:58 pm

Boulder CTO January Lunch with Jud Valeski

The Boulder CTO Lunch meets once a month with a guest speaker and covers topics and questions that startup CTOs should find interesting. This month, the group had Jud Valeski, who is currently the CTO at Gnip. Prior to Gnip, Jud started his professional career in technology at IBM as a software developer. In the past ten years he has spent about five of them coding (primarily C/C++), and about five of them in technical team management/director capacities. The bulk of his experience comes from Netscape Communications (acquired by AOL), with varying durations at IBM, Microsoft, and onebox.com (acquired by OpenWave).

I will share highlights of the discussion, but since this was a open, free-formed discussion, I am sure I couldn’t capture everything and not all my notes are completely accurate. Some of the notes also come from participants in the conversation and are not necessarily held by the discussion leader.

A question we ask each visitor, every month, What is a CTO? we do this because every CTO has a different answer.
“The title is pretty much irrelevant to me.” At a small company it doesn’t matter. It means something, it means a lot, at larger companies.

CEO is pure fantasy
Dev is pure reality
CTO is the bridge

Jud is a developer turned CTO, he explains this can be hard for some because a CTO brings some management responsibilities, which doesn’t always come naturally to all developers.

If you come from only management experience you can have a hard time with the CTO role because they don’t have the technical depth to make these decisions.

Important qualities of a CTO
* Technical Management
* Technical Direction (choose the tech to use, the approach, the design)

CTO role embodies the sense of leadership.

As CTO, you need a complete understanding of the business.

If the CTO is scattered that can be fatal. Be clear with prioritization and direction. If a person in the leadership position is confused it leads to a lack of confidence.

CTOs need to always be able to draw the system architecture. If you can’t, you are too detached.

To show those around you that you know what you are doing, you have to get down in the trenches and make some low level decisions with them. Backing up the decisions by explaining the technical merit of those choices.

Defining his role at Gnip
Push technical discussions along. Don’t let a topic be discussed too long when a decision needs to be made. Also, don’t cut off the discussion before exploring enough opportunities or you can make the wrong decisions.

At Gnip, defining the technical direction involved setting expectations that Gnip is an agile shop, uses pair programming, and uses lots of testing

One thing Jud measures the most is how well the team is going. If it isn’t going well, it is his fault.

A personal metric of Jud’s: if Gnip disbands tomorrow, every employee should be better and more knowledgeable than they were before they worked at Gnip.

Hiring
* Only hire people that are smarter than you.
* If you think you are the smartest in the room, there is an ego problem and it is hurting the business.
* The downside to this is it takes a long time to hire.
* Gnip might hire 1 out of every 120 resumes it takes the time to seriously consider.
* It is important to sit down and write code with someone, plenty of people can talk a good talk
* Hire generalist because they can learn and do anything
* Don’t just hire for the tech need, the team personality and fit are just as important.
* Everyone on the team has to be great people, not just in the office, but out of the office.

The Gnip hiring process:
Resume Screen -> 30 minute call -> group tech conversation -> half/full day pair programming

Jud was once a part of a team that went from 15-50 in 4 months, which was too fast of growth and it was a mistake.

As a CTO do you have to manage your CEO?
“Yeah, all the time, absolutely.”

Like any job you need to be careful about what you escalate to the boss. The CEO doesn’t want to hear about every little thing.

What can a CTO do to foster engineering growth?
* Let employees buy as many books as they want on the companies dime.
* If you can afford it do the same for training
* Encourage participation in users groups
* Churn what people are working on
* Force developers out of their comfort zones.

What do you do about slipping schedules?
“Anyone suggesting software stays on schedule is in fantasy land”

If you pin motivation, success, or failure to a schedule you are doomed.

Wins have to come from someplace, if you set a schedule and meet it celebrate.

Reconciling schedules with business realities is probably one of the toughest CTO jobs.

If you have shrink wrapped software schedules has a whole different meaning.

Don’t inflate dates just to make the schedule, any dishonesty anywhere in the chain is bad.

You need to be able to release internally all the time. Internally always try to release early and release often.

When falling behind schedule, you have to evaluate the severity of each bug and feature. If there is a known workaround, that changes everything. If there is a workaround then it doesn’t have to block a release. If there isn’t a workaround, then you have to decide if it makes sense to have a release missing that feature.

Thanks a bunch to Jud for sharing his thoughts with our CTO group. I also want to thank Tom Chikoore from Filtrbox for organizing the meetings, and Jon Fox and David Cohen who originally started our CTO lunches.

Written by DanM

February 16, 2009 at 10:40 am

Boulder CTO January Lunch with Sanjiv Bhargava

The Boulder CTO Lunch meets once a month with a guest speaker and covers topics and questions that startup CTOs should find interesting. This month, the group had Sanjiv Bhargava from StillSecure come talk with our group. Before becoming VP of product development at StillSecure, Sanjiv was VP of Technology at Symantec Corporation. Sanjiv was also involved in some startups that failed and others that succeeded (selling a consulting company he founded). I will share highlights of the discussion, but since this was a open, free-formed discussion, I am sure I couldn’t capture everything and not all my notes are completely accurate.

Remote vs. Local employees
Sanjiv has worked with geographically dispersed teams in the past, but recommends working with everyone under the same roof if possible. He said that for small teams it is very helpful, as you build teams you need to build relationships.

Corporate Culture
“One of the best parts of starting a company is you get to create the company culture”

A team is a reflection of the leader, or you can switch it around, a leader is a reflection of a team because the leader builds that team.

The first hire to a small team has a huge impact on corporate culture, which can be good, but be aware of it.

What makes a good team?
* getting the right team chemistry
* sometimes make a compromise on technical knowledge but not on culture and team chemistry.

As a small startup, you don’t have time for team building exercises, if you need those at this level you have the wrong people in the company

The corporate culture is set by who you are. For example, if your office has a ping pong table and you never play ping pong that sets a culture to never play – focus on work. To play or never play: either is OK, but your actions as a leader set it.

Problem Employees
Have an open dialog with a problem employee to figure out what is going on. Maybe things can be turned around.

In small startups you need to cut your losses on employees fast and early.

There is never an easy or easier time to get rid of someone.

Think of the other employees you have. Good startup employees know the bad hire isn’t working out, and they don’t like having to carry their dead weight.

Employee Training
“Sometimes it would take you 2 hours to do something, or it take 1 hour of training and 4 hours for the new employee the first time. You have to take the trade off.”

Evaluations
Everyone chimed in on evaluations from the group, some of the thoughts are below.
* Every 6 weeks have a quick meeting. “Here is what you did awesome, here is what you could improve”
* Discuss as part of a team. What can I change? What can we improve on as a team? Have them evaluate you as a leader as well.
* A quick weekly meeting. What is not going right? What is going well? Go over what goals were met from the previous week. Have a meeting to set goals for the week and the year.
* It isn’t about management recognition, it is about team recognition. Group support and group recognition.
* Don’t have meetings. Do it on the fly, why wait to tell someone something is awesome or something wasn’t up to par?

The CTOs Role
* Ask ten different people what is the role of a CTO and you will get ten different answers.
* The CTO role is decided by what fits the company.
* It is a role that is a combination of business and technology.
* Two types of visionary CTOs, “How do I grow the business?”, or “How do I scale the technology or broaden the feature set?”
* One of the biggest mistakes we make is we try to pigeon hole people into boxes and defined roles.

Thanks everyone for attending our January CTO lunch. Thanks to Sanjiv for helping lead a great discussion. Also, thanks as always for TechStars for hosting our group. If you are interested in joining our CTO lunch shoot me an email dan devver.net, and I can get you on the email list.

Written by DanM

January 23, 2009 at 2:24 pm

Posted in Boulder, Misc, TechStars

Ruby people on Twitter

The Ruby community is always quickly moving, changing, and adopting new things. It is good to keep your ear to the ground so you can learn and adopt things that the community is finding really useful. There are a number of ways to do this, like watching the most popular Ruby projects on GitHub, most active projects on RubyForge, Ruby Reddit, or listening to the Rails podcast. The way I have found most effective is following a good collection of the Ruby community on Twitter, many of the most active Ruby community members and companies are on Twitter. It is where I have first heard of many things going on in Ruby like the recent Merb/Rails merge.

You can find a great list of 50+ (now 100+) Rubyists to follow on Twitter from RubyLearning. I thought we might as well give out a list of some of the Ruby people Devver.net is following on twitter.

technoweenie
jamis / Jamis Buck
obie / Obie Fernandez
chadfowler / Chad Fowler
engineyard / Engine Yard
d2h / DHH
rjs / Ryan Singer
jasonfried / Jason Fried
37signals
foodzie
fiveruns
_why / why the lucky stiff
gilesgoatboy / Giles Bowkett
dlsspy / Dustin Sallings
julien51 / julien
rbates / Ryan Bates
defunkt / Chris Wanstrath
chrismatthieu / Chris Matthieu
littleidea / Andrew Clay Shafer
headius / Charles Nutter
bascule / Tony Arcieri
atmos / Corey Donohoe
ubermajestix / Tyler Montgomery
raganwald / Reg Braithwaite
chriseppstein


of course I have to give a special shout to ourselves:

danmayer / Dan Mayer
bbrinck / Ben Brinckerhoff
devver.net

If we should be following you also send us an email at contact@devver.net, and we can hook up on Twitter as well.

Written by DanM

January 8, 2009 at 2:08 pm

Posted in Misc, Ruby, Tips & Tricks

Boulder CTO December Lunch with Tim Wolters

The Boulder CTO Lunch meets once a month with a guest speaker and covers topics and questions that startup CTOs should find interesting. This month, the group had Tim Wolters from Collective Intellect come lead the discussion. Tim is a serial entrepreneur currently working on using artificial intelligence and semantic analysis to extract knowledge from unstructured text found in social media. Collective Intellect’s customers use this analysis to inform and measure the effectiveness of their PR and marketing strategy.

Tim is considering working on a book, a startup survival guide for CTOs. Some of his ideas for the book helped lead our discussion during our meeting. I will try to present my notes under topic headings that Tim mentioned, but since this was a open free formed discussion, I am sure I couldn’t capture everything and not all my notes are completely accurate.

The Idea
People should keep a journal of ideas. Tim keeps a journal which he updates, tags, and adds ideas. On any idea, keep track of what is near term, what resources are needed, what is the cost, and what does the related market look like. (I highly recommend this! Ben and I keep a wiki, which has grown to be an incredibly useful resource and was the initial starting point for our last two companies)

Ideas should have an “Aha!” factor that makes you wonder why someone else isn’t already doing it (or some emotional appeal that makes lives better).

During the first few years of a startup you can’t work on all the ideas that come to mind, that is why it is best to keep a journal, just add little notes to the idea to keep them in the back burner.

Talk to others about ideas and perhaps have a group move on an idea and lay the groundwork while leading as an adviser.

Don’t be worried about people taking ideas. After starting a few companies you know how hard it is to really bring something to market.

What about brainstorming for ideas with a group?
Brainstorming groups have never worked for Tim, it just hasn’t worked out. If you have the right people around the table (people that can make things happen), it could work, but Tim hasn’t seen it.

Ideas depend a lot on timing in the marketplace. If the market is moving slow you can slowly look at an idea. If the market it really moving fast you need to spin it up quick and get a lot of people working on it to really make a move on the idea.

Look over your ideas once in awhile and see what still really interest you.

The Role
As a CTO, you paint a landscape of the product and market.

There are two kinds of CTOs: tactical and visionary. Tactical CTOs are internally focused, manages the team, makes the day-to-day tactics so the product gets out there. The visionary CTO sees where the product could go in the market place, signs early deals and customers, looks for features that lead towards or away from markets/competitors/partnerships. The visionary isn’t working on architecture but the market landscape, what partners will benefit the product or get it out sooner.

CTO should be thinking about things such as the three hardest problems that the company faces, so they know what will also be affecting their competitors.

People who liked architectural purity but learned it isn’t as import at winning at the business end up making great CTOs.

CTOs need to stay involved with customers to make decisions about the project innovation and development. Stay active on sales calls, talk with sales people, read all the RFPs.

Becoming the CTO vs VP of engineering?
Are you good at managing or not? VP of engineering is a managing role. If not, divide off the management as soon as possible (in his case that wasn’t possible until the company was about 20 people).

Good sales people leverage a CTO as a company evangelist. If you are a CTO you have to be comfortable with presenting and publicity. You will be at conferences, sales calls, giving presentations, and fund raising. If you aren’t comfortable with these things, get comfortable with it.

time spent:

  • 10% guiding research
  • 30% Sales
  • 30% Partnerships
  • 30% Biz Dev Dealings

Reputation
After some startups, successes, and expanding your network things like getting a team, funding, and getting a startup off the ground are much easier the next time.

It will take 3 to 5 times longer than you think to get a project going if you are an unknown entrepreneur with no reputation.

Don’t solve the big unsolvable problems first, the first time start with smaller problems and develop a reputation while solving them. Angels and VCs aren’t funding research efforts, don’t just chase after big impossible goals.

After a company is bought, it makes sense to make the purchaser successful. It builds on your reputation.

Become a big fish in a small pond and then move to a bigger pond.

Putting together the team
The ideal size for an engineering team is 6-8 people, bigger teams have difficulties maintaining the right amount of communication.

For hiring, Tim personally sits down with the key hires, and if it is research he does interviews with applicants as well.

The Traps and Pitfalls of Startup Companies
3 things that companies get stuck on that can kill the company.

  • Problem with getting over enamored with their original idea, startups must be able to adapt
  • Getting enamored with the research technology, for technology’s sake
  • Getting emotionally tied to architecturally purity. Working on layers of abstraction on abstraction to avoid some possible future problem.

Other things that kill companies (which are kind of like a marriage)

  • Not the right chemistry
  • Bad culture or losing company culture
  • Employees need some sense of allegiance. If they don’t have it cut them immediately
  • Lacks a culture of adaptability
  • Not thinking about how to quickly get to the market and solve problems

Continual code death march. Sometimes companies go on code marches to get something to the marketplace. This can’t be done many nights or it will start taking a toll on other aspects of your life. Strive for balance.

During a startup, you continually are hitting false summits, you think that if you could just get that contact, solve that roadblock, pass this milestone, or make this key hire then everything will fall into place. While these are important as milestones and you should celebrate them you are not done. Or rather, it typically doesn’t get any easier. What it does is takes more risk out allowing you to go solve bigger/other problems.

When founders or others in a company argue, which they need to do sometimes, don’t do it in front of everyone. Discuss disputes offline, reach agreement and present a unified front to the company.


Thanks so much to Tim for sharing some of his thoughts with our group. I will leave you with a final question and quote. Someone once asked why Tim likes to start companies?
“I like to pick where I work and who I work with.”

Written by DanM

December 11, 2008 at 9:50 am