As I attend more and more Startup Weekends, I’m beginning to notice a trend in the attendees: expectations. The last couple of Startup Weekends that I was involved in, I played the part of “mentor” — going around to teams, discussing their project management and tech strategies, advising — which was great, but I’d like to point out a few things I think are important for a would be Startup Weekender to know going in.
If you know Startup Weekend, then you know it starts with pitches. Everyone that desires can bring an idea and give a 60-second pitch to the attendees. After all the pitches have been given, a vote is taken and people split up into to teams to work.
A question I get asked a lot, “What if my idea doesn’t get selected?” as to say “What am I going to do then?” My feeling is that in a lot of ways Startup Weekend is about practice. Practicing your pitch. Practicing working with a new team. Practicing working with constraints. Practicing your business development skills. Not having your idea selected shouldn’t signal the end for you.
The truth is that failure is at the heart of being a great entrepreneur, as long as you understand that failure doesn’t mean defeat. If your idea doesn’t get selected it could mean your pitch needs to be tweaked. Or maybe your idea targets the wrong market?
But don’t give up on Startup Weekend. Enjoy the company. Dig in to the challenge. Learn something new.
Startup Weekend is an amalgamation of people with different skills. Business majors, designers and developers are the biggest, all with something interesting to offer Startup Weekend. Once the voting completes there’s a mad dash for one type of attendee though: the developer.
I believe this is rooted in the fallacy that you are required to produce a fully working product by the end of startup weekend. The goal is to produce a viable business plan that you could pitch to someone and presumably get funding; in the case of Startup Weekend your “someone” is the judges.
The definition of viable reads:
Capable of working successfully; feasible
Success in this context is defined as attracting customers and making a profit. Unfortunately having the mostly complete product does not guarantee you will find customers. More likely, going heads down and building a complete product without getting feedback from customers means you will have features that no one will use and/or damages your product. This is a waste of your most precious resource: time.
Where do I think your time is best spent in a Startup Weekend?
I believe if you become comfortable with these truths and work together cross-functionally to build the best pitch possible, you are on your way to having a successful Startup Weekend experience. Even if you don’t win you’ve networked, got some practice in building a startup and you’ve learned something about your idea that could help you take it to the next level and build something amazing.
Enjoy!
My dictionary defines the term gentrify as the process of renovating property in order to improve one's way of life. I work in Chicago and watch this process on a daily basis as the final vestiges of one of the larger low-income housing complexes disappears with earlier buildings having been replaced with quaint brownstones. Just how much this has improved some of the former residents life is questionable but one can't argue that the former living conditions were not ideal for building healthy community. As a software developer, watching this reconfiguration of space makes me think of much smaller scale changes that need to occur in many corporate software development environments.
Most corporations use the office cubicle to provide a controlled and quiet working environment for their knowledge workers. After all, the company has made a significant investment in all that brain power and wants them in a distraction free environment so they can work at peak performance. But software developers do not peak when working in isolation. The research is clear that software developers are more productive when pair programming. So why not create a physical environment that encourages them to do so?
There are two commonly heard arguments against removing the cube walls and creating a shared work environment. The first is the fear of taking away something from employees, in this case, their cube. The second is that an open environment would be too distracting and developers won't be able to concentrate on their work. Having worked in multiple of each environments and helping to facilitate the transition to shared spaces, I can say that these fears are "mostly" unfounded.
I said "mostly" unfounded because there is a good chance that you will lose a developer or two. Why? Because an open work area generates inherent pressure to produce. It now becomes uncomfortable for those developers that have quit caring about their craft and are simply collecting a paycheck. Over time, no matter how strong the friendships, the team will grow weary of their lack of discipline and commitment, making it difficult for those developers to continue on as before.
Combatting Noise with the Private OfficeIf you spend any time researching the ideal work space for developers you will find respected resources touting the move from cubicles to private offices. Most of these are based on research that noise decreases productivity. I won't argue this when looking at the impact on productivity for the solo developer. This doesn't apply to developers who spend their time pairing, which is one of the main motivations of the collocated space.
The main reason for creating a colocated work space is to increase productivity. By some measurements (see references), simply moving a small team to an open space can improve productivity by 100% . While each team's mileage may vary, even a much smaller increase in productivity should quickly recover any costs incurred in the process and will achieve our goal of increasing velocity.
Another reason high up on the list for renovating your work space is to encourage and facilitate pair programming and with pairing comes a higher degree of focus. Those mental lapses that would send us off to check personal e-mail or make a quick call are no longer easy to act on when another individual is depending on your immediate involvement.
When developers are working alone, they are highly susceptible to external interruptions from business users who happen by or even their own team members who are between tasks. When developers are actively engaged in a pairing session, those social visits become more obviously intrusive.
While not intuitive, a big benefit of an open space is the increased communication that occurs on the team. With all of the conversations going on at the same time, you would think no one would be able to concentrate, but the reality is that we are extremely adept at filtering our environment. I'm always pleasantly surprised when I'm focused on a problem with my pair and a word or two spoken by a different pair nearby will trigger some synapse that allows me to surface from my current train of thought, provide them direction, and then re-enter my work with the help of my pair (see "Cocktail Party Effect").
The open work area makes it much easier to determine the health of the team. Now, every member can see both the good and bad practices that occur as part of the team. Are developers pairing? Jumping on stories as soon as they are available? Or are they dragging their feet and spending time alone working on lower priority tasks that interest them? Increasing the visibility of current activities helps keep the team on track at all times.
Research says that knowledge workers are most productive when working about 35 hours a week, yet most of us are still working the standard 40 or more hours that were created as the norm for industrial workers. An open work environment can stimulate creativity in a social environment which helps us keep work flowing when we begin to stretch our limits. In the end, it can ultimately make returning to work each day something we enjoy.
There are a few logistics to keep in mind when setting up a shared space for your development team. The following the guidelines will help avoid unexpected roadblocks on the way to maximizing productivty.
One hard rule I have seen for how much space to allocate was 50 sq. feet per developer. In addition to the developer work stations, this included private meeting space and storage for personal belongings and team documentation, etc... A "rule of thumb" approach is to provide each developer with a large work table, roughly 5' by 3', and set the tables back-to-back in one or two rows. Keep in mind that you want to make it easy for developers to sit alongside each other and code. A mistake is to build a space out with just enough room to comfortably sit each developer. This will cause scenarios where pairs cannot easily sit next to each other to access a shared keyboard or monitor.
Place one large monitor per table and give the developers laptops to work from. The goal is to make it easy for a developer to pick up his work and move to a new pair. Yes, pairing typically means working on the same box but the flexibility that comes with being able to quickly reconfigure where members are sitting can enhance productivity.
Setup wireless internet access and provide wireless keyboards and mice. Again, the idea is to remove clutter and make it easy for team members to quickly reconfigure to work with each other. Anything that inhibits developers easily working together should be eliminated.
With all of this talk of open spaces, there is a need for walls. Moving your team to a large room with outer walls helps separate them from distractions not related to their work. More importantly, it provides them with space to hang information radiators such as burn up/down charts, action item lists, and/or design diagrams, all of which help keep teams focused.
One of the things that bothers me a great deal about software development is that it is Sisyphean. We spend a lot of time taking that boulder and rolling it back up the hill. When we get to the top of the hill, we see lots of boulders at the bottom and some other poor souls pushing them to the top of the hill again.
Part of this is entropy. Systems do tend become disordered over time. But the terrible truth of software development is that software doesn't become disordered by itself, it becomes disordered because we touch it. We change the code and the changes can be good or they can be bad. It requires constant effort to keep a code base clean. But, like the boulders, we slide. Sometimes we don't even know that we are doing it. A while back, I met a manager who is part of an organization that keeps detailed records about the state of their code and he said that often they can see cases where developers were letting some cruft build up but they weren't aware of it because the code remained understandable to them. It was a variant of the 'boiled frog syndrome.'
In the end, we're all human. We can look at ourselves and consider ourselves flawed because of the mistakes we've made, or we can flip things around and look at the environment and see what we can do to make things easier.
I've been thinking about this sort of thing for a while, it really came home to me the other day with this article.
Reseachers have determined that if you are a convict who wants a favorable outcome in a parole hearing, you are much better off if your hearing is after lunch. It doesn't seem to matter who the judge is, the severity of the crime, or the amount of incarceration. Prisoners were granted parole 65% of the time right after lunch with the amount of time dwindling toward zero at the end of the day.
This is a very sobering thought for people want to see themselves and others as entirely self-determined rational actors.
I don't know what the outcome will be (if any) for the legal profession, but they do have a chance to address the problem by altering their processes and environment. It makes me wonder what we're missing and whether we can do the same.
Developing software is about a lot more than just writing code.
One of the most important aspects of a great software development team is their ability to cooperate in a meaningful way that increases quality across the team.
If the members of a team don't invest in a culture of achievable quality, then the code will suffer.
By achievable quality, I mean not only a standard to work towards but also the context and guidance to achieve that standard.
In many ways, that context and guidance is more important than the standard itself, since without it the standard becomes meaningless.
If the members of the team who fall towards the lower end of the skill spectrum aren't given meaningful tools, guidance, and feedback to meet an agreed upon standard of quality, they won't be able to deliver.
Furthermore, I've noticed that some people become paralyzed and unable to deliver if there's a standard being set that they don't understand. It ends up creating a sense of fear that whatever they're doing won't pass this nebulous standard of quality.
There are many ways to set a rigorous standard and encourage everyone's participation in its enforcement, and all of them rely on careful communication that makes the standard achievable for everyone.
The end result is a team that not only holds themselves to a high standard, but understands that a culture of quality emerges from the actions of individuals cooperating to achieve it.
CSS-Spriter is a project that Tyler Jennings and I developed to eliminate the tedium of CSS sprite creation. While developing it, we stumbled across a style that's a combination of outside-in and bottom-up testing. It's a style that's helped us with other projects because it attempts to answer what levels of testing are appropriate and what time to do it.
First, lets understand what sprites are and how CSS-Spriter can help. Web browsers only request page resources a couple elements at a time, so, one way to reduce page load times is to reduce the number of connections needed to download everything. Sprites do this by combining many or all of the image elements into one large image. Instead of 30 requests to different images, you now have one request that delivers all 30 images to you. You then have to create css rules for every image to only show a small part of the total image. If you create the css by hand, it can be a tedious and error prone process that's also a pain to update.
CSS-Spriter automates the sprite generation process. It looks at the directories where you store your PNG files, and then combines them into one larger image. It then does the math and calculates all the CSS image offsets for you. Since CSS-Spriter is written in pure Ruby, this means you can use it in your JRuby, MRI, or Rubinius projects. There are no native extensions to compile! Also, it uses the fast and efficient chunky_png library to read and write PNG files. It works as a stand-alone app or as a rails plugin.
Since there were no pure ruby PNG parsing libraries like chunky_png when we started this project, we had to make our own. Tyler came up with a spike over the weekend that loaded an image and saved it. It was from this spike that we slowly added features and evolved the design. When developing the spike, Tyler didn't worry about design or testing. He was just concerned with proving one simple thing - can we read the png file format? He constructed the spike so it was the bare minimum needed to represent the whole stack.
The next step was to wrap a couple high level integration tests around the spike. We would use these as a sanity check for each change we made to the system. We made these tests high level enough that we could radically change the implementation of the system and they would still pass if the files were created correctly. We could then refactor the system and add features to slowly evolve the project toward a better design.
Tests were then added only when a few conditions were met. We put tests around the methods that were the most complex in the system. These regression tests were useful to ensure that we didn't break anything when we refactored them to reduce the complexity. We also put tests around the parts that absolutely had to work because a spriting library wouldn't be very useful if you saved a corrupt file format. When we did find a bug, we created a failing test and knew we fixed it when we passed.
We had to design these tests carefully to make sure we weren't accidentally implying an implementation. There were some parts of the library that quickly became stable, but some of the other code would keep the same features while radically changing the implementation. These tests would only tie down the parts we knew weren't changing. The general principle that we followed was "test what you know" because we wanted freedom to change our minds about the uncertain parts of the code. this strategy eliminated situations where interfaces were locked down prematurely in tests. We could radically change our mind, and only needed to create tests for the sections of code that were stable enough.
This testing strategy helped answer the hard questions of testing. It was clear what parts of the app we should test, and how we should test them. We also kept the fun hacking vibe of the app throughout the process because our testing allowed us to radically change the implementation without punishing us. For more information about CSS-Spriter, check us out on github
Obtiva's purpose is to be a role model to the software industry. And the big, hairy, audaciuos goal that we're aiming for is to become the most respected software development company on the planet. Back in 2008, when Kevin, Tyler, and I asked ourselves who we saw as the absolute best role model in our industry, we immediately and unanimously thought of Michael Feathers. Then we all laughed at the impossible propsect of Michael ever wanting to join our little company. Thanks to Obtiva's technical and delivery excellence, marketing, inspired learning, community leadership, business strategy, and recruiting over the last 3 years, we put ourselves in a position to attract Michael to join us. And he was as excited as we were about the opportunity. It's an opportunity for him to be the chief scientist of a company well on the way toward making a mark on our industry. It's an opportunity for all of us to learn from Michael and to meet new people and ideas through his work. And at the bottom line, Michael will help Obtiva's business through boosting our training and coaching opportunities. We believe an Obtiva with Michael is a more profitable Obtiva.
When it comes to hiring "names" in the software development community, we are opportunistic.
Noel joined us when his previous employer had a financial hiccup, and we've been thrilled to have someone who seems to exhale books, leads Studio projects, performs training enthusiastically, speaks prolifically at conferences, and is now overseeing Carl Thuringer's apprenticeship. As with Michael, we believe hiring Noel was in everyone's best interest.
I contacted Bo when he announced that he was looking for work after Dr. Nic left Mocra for Engine Yard. Again, as with Michael, we had put ourselves in a position to attract someone as prolific as Bo to move from Australia to Chicago. He sees our trajectory. And we need Senior Consultants like Bo to lead projects and create opportunities for our more junior people to ramp up in the midst of successful projects.
Charley Baker is our most recent hire. I've known Charley from back in the years that I was involved with the Watir project. After RubyConf last year, Ryan Briones re-connected us with Charley because Charley was an experienced Rubyist in Denver who seemed to match up well with our values. After a few conversations with us, Charley became a rabid Obtiva fan and has been working patiently with us to figure out how he can start developing new business for us in Denver. And then, when we had an opening on our Groupon Denver team, Charley jumped on the opportunity to join us as a Consultant. He intends to help us find our first long-term Denver clients while working with us on Groupon. Charley does not have a strong Rails or web development background, so we had planned on having him sit in our May Rails TDD Boot Camp. But since that was postponed until later this month, we figured we could kill two birds with one stone by having Charley get immersed in Rails and find some potential Denver projects for us by sending him to RailsConf. It's an atypical first week for an Obtivian, but from a delivery standpoint, I need Charley as strong at Rails as soon as possible, and from a Denver standpoint, the sooner we land our first local client, the sooner we can build a sustainable practice there where people aren't having to travel to Chicago every month.
Assuming we don't feel a dip in demand, we're going to continuing hiring Obtivians of all experience levels in the coming years at a responsible, sustainable pace. I'm encouraged that it feels like our culture has only improved as we've grown these last few years. This comes from apprentices growing their craftsmanship, developers with high standards, consultants that communicate effectively, senior consultants that lead by example, and our leadership team being frugal in our decision-making, but decisive when opportunity knocks. The people who join Obtiva are being hired because we firmly believe they are going to add to our culture, our bottom line, and most importantly, help us fulfill our reason for being: to be role models to our industry.
Every project I've worked on has been underscored by a sense of urgency and a high degree of pressure to deliver value quickly.
Frankly, I don't think I would enjoy my work very much if that were not the case. The feeling of "we're doing something amazing, it must be delivered YESTERDAY" is invigorating!
That being said, difficult experience has instilled in me the importance of balancing a healthy pressure to deliver new features now with bigger picture thinking. Things can get out of control quickly in a “get it done now” atmosphere, and it is common in such cases to skip the review and refinement part of the test driven development process, or worse, skip testing altogether.
This becomes expensive, fast. When developers stop running tests, start making mistakes, and clutter the system with untested or substandard solutions, problems happen. Everyone switches to critical bug fixing mode and stops delivering new functionality, the overall pace of development slows, and even the bug fixes take more time because of the overly complex or confusing code that was written in haste. It’s a textbook case of lose, lose, lose.
Taking the larger context of a system into account and refactoring code accordingly, as a regular part of a software practice is one of the surest ways I know to ensure consistent delivery schedules, avoid costly errors, and keep the total cost of ownership for an application predictable.
Simply put, refactoring is a calculated investment in the quality of a system, which helps to ensure that your application and your team can respond quickly to changing requirements and continually add value to your software project.
For legacy systems, however, refactoring can pose a different set of challenges. Often there are no tests, bad tests, or lost requirements. In many cases, the original engineers who created the application are no longer accessible, so finding answers to questions about why a certain approach was chosen becomes much more difficult.
To that end, here is a high level overview of the process we use for refactoring legacy code, with which we have had consistent and repeated success:
It is important to remember that improving an existing system is more like a marathon than a hundred yard dash.
In my experience, teams who have had the greatest level of success in maintaining and building upon legacy systems are those who make refactoring a regular part of their daily process. They take measured, incremental steps toward improving the software they deliver, never losing site of the larger scale goals of the project and the value proposition that drives it.
There is far more to this topic than either time or space allow for here, so see the links to resources below.
Always feel free to reach out to me, or anyone on the Obtiva team, if you could benefit from the insight or advice of someone who has suffered the pitfalls of a legacy system, lived through it, and learned how to succeed in even the worst legacy codebases.
Resources:
Recently on a project I was tasked with creating an extremely long-running task that is intensive in unknown ways on our database and not idempotent. This meant unforeseen performance issues could cause us to have to kill our long-running task and leave us in a state that was painful to recover from.
To alleviate some pain I decided that I would trap the kill signal. If you pressed Ctl-C once, it would output a message “Press Ctl-C one more time to Kill now. Otherwise, the process will terminate at the next round.” This idea I stole from Ruby projects like autotest and mongrel. In autotest, pressing Ctl-C tells autotest to run all tests manually whereas pressing Ctl-C twice means quit autotest. In mongrel, Ctl-C starts the shutdown process, but waits for each child to stop it’s request before exiting. Ctl-C again tells mongrel to abort and exit immediately.
This pattern can be extremely powerful and is super easy to implement in Ruby. For instance, let’s say I want to output a message when exiting due to Ctl-C, here’s what that code might look like:
trap("INT") do
puts "Whoa there big dogg. I'll exit in a second!"
sleep 1
exit
end
while true
# infinite loop to simulate "long running process"
end
Here we’ve told Ruby to capture the INT signal, which is POSIX signal that is emitted when you press Ctl-C. In this particular code, we’ve decided to be nice and exit when our user sends our program SIGINT. A funner version of this program could be this:
trap("INT") do
puts "I'mma let you finish, but SIGKILL is the best POSIX signal of all time"
end
while true
# infinite loop to simulate "long running process"
end
This is probably not useful though. How about a more practical version:
$shutdown = false
trap("INT") do
if $shutdown
puts "Prematurely exiting"
exit
end
puts "Starting shutdown procedure"
$shutdown = true
end
while true
# infinite loop to simulate "long running process"
if $shutdown
sleep 10 # simulate shutdown procedure
break
end
end
Here we setup some global state for our process in $shutdown. It tells our event loop when to start the shutdown procedure. When the shutdown procedure is finished, the event loop will exit and the process will terminate. We can also terminate the program by sending SIGINT twice. This is the case where we need to subvert the shutdown procedure and just shutdown.
A practical example of using signal trapping is in my cgiup gem; a gem I wrote for running a single “CGI script” as an application mounted at http://localhost:2000. Here is the juicy stuff:
#!/usr/bin/env ruby
# From: https://github.com/ryanbriones/cgiup/blob/master/bin/cgiup
require 'webrick'
unless ARGV[0]
STDERR.puts "usage: cgiup [PATH TO CGI SCRIPT]"
exit 1
end
cgi_script = File.expand_path(ARGV[0])
unless File.exists?(cgi_script)
STDERR.puts "CGI Script: #{cgi_script} Not Found"
exit 1
end
server = WEBrick::HTTPServer.new(:Port => 2000)
server.mount('/', WEBrick::HTTPServlet::CGIHandler, File.expand_path(ARGV[0]))
trap("INT"){ server.shutdown }
server.start
Here we have the same basic setup as in our examples above except that we’re not tracking state in a global variable. Instead we have an object, our WEBrick::HTTPServer instance, that just gets a method call to #shutdown when SIGINT is received. After we setup that trap, the server’s event loop is started and runs. This is the more common use case for signal trapping.
There are other things you could do as well. For instance in the autotest example there is a timeout of a few seconds or so when pressing Ctl-C before all tests are run. If you send SIGINT again during that time period, autotest will stop instead. Also, trap isn’t only for SIGINT. You can capture any POSIX Signal with trap. For instance, many daemonized servers implement SIGHUP for log rolling or configuration reloading. The possibilities are ENDLESS… within the list of POSIX signals your operating system implements. See the linked Wikipedia page for a list of well known POSIX Signals and their traditional uses.
Well, that’s the basics of signal trapping. It’s another tool in your box for great good and great fun!
If you've ever been part of an agile project, odds are good that you've participated in a daily stand-up meeting. The goal is to communicate status, identify obstacles, and commit to an action plan for the day, while minimizing the time the team spends in meetings.
The basic format is very simple. The whole team meets everyday for a quick (less than fifteen minutes) checkpoint. Everybody takes a turn answering three questions:
If you've participated in daily stand-ups more than just a few times, odds are also good that you've seen them fail. Given such a simple format, why do stand-ups so often run astray?
One of the biggest culprits is lack of preparation. Those awkward pauses while someone is trying to remember what they did yesterday throw off the rhythm of thestand-up, causing it to drag on and creating opportunities for it to degenerate into a planning session or social event. In order to keep the standup short, high energy, and effective, everyone must show up prepared to answer the three questions.
Try taking a minute or two before the stand-up to jot down your answers to the questions on a sticky note. Bring it to the meeting with you, and use it as your guide when it's your turn to speak. Stick to your script, and "take offline" other conversations the spring up.
After the stand-up post the note somewhere on or near your desk. Tomorrow it will serve as a reminder of what you committed to today.
Over the last few months, Obtiva's leadership team and senior consultants have decided that we won't plan to hire any more senior consultants. Instead, we have expanded the pay scale for consultants and only recognize new senior consultants after we have seen them live up to our values, hopefully stretching our definition of senior consultant and raising the bar on the people already in those roles.
This recognition is bestowed by our senior consultants, and it must be unanimous. Consultants are nominated and then championed by someone who presents their case to the group. We discuss, vote, and then recognize. Last week we discussed and voted. Today it is time to recognize Obtiva's two newest senior consultants.
As we reviewed what both of these guys have accomplished over the last year, all of the senior consultants felt at least a little uncomfortable about the level of awesomeness these guys were achieving. This is good, Obtiva's purpose is to be a role model to our industry, and the only way we're going to live up to that is by steadily raising the bar of what we expect of ourselves.
While there are a lot of differences between these two people, one interesting similarity was the way they started at Obtiva: in a contract-to-hire relationship. Due to a variety of variables, when Obtiva first met these guys, we weren't 100% sure they were going to be successful with us and wanted to take it a bit slow. In hindsight it seems like we were silly to hesitate. But I wonder if starting our relationship without a full commitment actually accelerated the progress these guys made toward their achievements. It's something we need to consider.
I first met Ryan at Software Craftsmanship North America in 2009. He was visiting from Ohio and expressed interest in moving to a bigger city like Chicago, New York, or London. We kept in touch over the following months and when the time came for me to find someone to replace me on Mad Mimi, we chose Ryan. He left his wife Stephanie behind in Ohio while he lived in Obtiva's corporate apartment with our apprentice Ethan Gunderson. Ryan was confident he would quickly win our confidence, receive a job offer, and then bring Stephanie to Chicago. He was right, but he didn't squander his time living with Ethan.
Ethan was an apprentice at Obtiva from November 2009 to May 2010, and Ryan played an important unofficial mentoring role in Ethan's apprenticeship, which I believe has contributed to Ethan's success. Ryan befriended his flatmate and the two of them have launched two successful endeavors together in the year they've known each other.
Ryan quickly proved himself to be invaluable on the Mad Mimi project, and we hired him within the first two months of working with him. As Obtiva's day-to-day relationship wound down with Mad Mimi and they ramped up their own development team, Ryan transitioned into a slightly larger client. As with Mad Mimi, Ryan was a reliable, productive developer at Groupon, a good example of what Groupon CTO Ken Pelletier described in his interview. Ryan rolled out of Groupon in March to lead a project at one of Obtiva's key clients in Chicago where he has shown an ability to consult simultaneously at the technical and organizational levels, and has received rave reviews from his clients in the process. (You'd appreciate this feat more if I could tell you which company he was consulting at.)
All that said, the aspect of Ryan that really stands out is his passion for community engagement. Ryan is an ambitious, fearless extrovert and has thrown himself headlong into the Chicago development community, representing Obtiva at countless user groups. He has spoken at half a dozen conferences in the last year, most recently at the Scottish Ruby Conference where he spoke on a topic he plans to eventually adapt into a book.
The future is certainly bright for Ryan Briones, and we feel fortunate to be able to recognize him as one of Obtiva's senior consultants.
I met Scott Parker in late 2009 after he responded to an email I sent to the Polyglot Programmers of Chicago group (which is now in hibernation). One thing led to another and since Scott's professional programming experience was exclusively on the .NET platform, Scott started with us on one of our infrequent .NET projects. Because .NET is outside of Obtiva's typical project portfolio, we were tentative and brought him on as a contract-to-hire. You can read a lot about Scott here, where I told a few stories about the intersection of passion and competency.
But there's more to tell, and a lot of it is too wrapped up in Groupon details to talk about, but suffice to say that Scott has created a multitude of raging fans for himself (and Obtiva) at Groupon. If you didn't click through to my previously written story about Scott, you'll need to figure out how in less than a year this guy went from .NET subcontactor to epic Rails project leader inside the fastest growing company in the history of history.
In Scott's copious free time, he has co-founded the Chicago Software Craftsmanship group and is currently working on a fall software craftsmanship workshop series at some university called Notre Dame. Like Ryan with Ethan, Scott also took the time to mentor someone in his off-hours who later became a full-time Obtivian, the fantastical Dan Melnick.
In the opinions of Obtiva's senior consultants, both Ryan and Scott should be recognized as Senior Consultants. They have set the bar high for future (and existing) senior consultants and we're excited to recognize them today.
