Agile delivery needs design facilitators

With the growing awareness of the need to integrate user experience design into agile delivery, there is now a better recognition of the role played by design facilitators in enabling good design faster.  I wrote a blog post to share my insights on what should be a design facilitator's playbook:

A design facilitator's playbook

Would love to hear your thoughts and insights!


How would you describe RubyMonk's interface?

We receive a lot of love from our users about RubyMonk's visual design. And while we agree -- it's super cute! -- the site's visuals are hardly its interface. The "user interface" for RubyMonk is really the boundary between the student and the mentor.

How do we evaluate your code? How do we decide whether it is correct or not? These are the interesting questions in the user interaction. And, as emerges in the design of any product, these questions highlight the necessary unification of form and function, engineering and design, purpose and path. When you boil it down, the purpose of RubyMonk is to automate the teacher. On some level, this goal might seem akin to beating the Turing Test. In its current incarnation things are much simpler, of course.

I've explored this idea a bit in my post "defining the interface for rubymonk". Take a look and check back soon as I take this idea forward to discuss the yin and yang of tests and the boundaries they exercise.


Why you should respect deprecation warnings

At C42, I have worked on multiple Ruby on Rails migration projects. A simple task of upgrading an application from Rails 2.3 to Rails 3, can take anywhere from two days to three months. After such experiences, I have developed a small set of rules to make sure, my projects don't run into these two to three months long upgrades. A blog post by me on, how a simple discipline of fixing deprecation warnings can help you maintain your ruby applications in the long run.


C42 Launchpad - bridging the gap between hackers and the industry

At C42 Engineering, we spend about 108 man hours for every good developer we hire. For a small product company, I would rather spend that time developing features. We've always wanted to hire more awesome developers with less effort, and I think we may have a way to do just that.

We receive about 30-40 resumes a month. Our interview process, although time consuming, allows us to know the candidate better. Even before we call them to our office, we spend about half an hour with each candidate on the phone. Every face to face interview takes about 6 hours. After this extensive investment of time and energy, we consider ourselves lucky if we hire 1 developer a month, i.e. conversion rate of 2.5%, something we always wanted to improve.

While speaking with other startups at RubyConf India 2012, I realized, rather, that a 2.5% conversion rate is extremely high. I have heard horror stories of interviewing 150 candidates to hire one or two developers. The point is, businesses spend enormous amounts of energy and money in the hiring market with returns that are too low to be considered acceptable.

If we ask any consultancy or product company what skill set they would like prospective hires to have, the following common points come up over and over:

  • Understands what is good code
  • Understands maintainability
  • Understands Object Oriented Programming principles
  • Familiarity with TDD
  • Deployments and DevOps
  • Awareness of standards and conventions

In summary, every business needs developers who care about good code and are capabale of being productive from day one.

The missing rockstars

Most engineers who don't make it through our interview process are asked to apply again in six months. We don't do it just out of politeness, but because we actually believe that they can in time grow to become the capable developers we need.

These developers have the potential and inclination to become experts, but lack the correct exposure and guidance. Focused training on OO, TDD and Agile, with discussions around nuances of development practices and principles will convert these talented folk into the rockstars that every company seeks.

As always, we gave this feedback to the candidates in question. A consistent pattern emerged where candidates would get back to us asking for more information on how they could go about learning the requisite skills.

Unfortunately, there are no organizations like hacker/school in India, places that expose programmers to the art of software craftsmanship. Be it universities or university-like classroom training programs, they just can't keep up with our fast moving industry. The gap is already large and growing every day.

Most lot of these skills are best learned by working closely with experienced developers and following practices for an extended duration. A 2 or 3 day workshop is useful for knowledge transfer, but it's impossible to develop discipline or grok the principles underlying the methodology in that short a duration.

The launchpad

C42 Launchpad hopes to be an answer to this problem. A 4-6 weeks full time hands-on workshop that will cover everything C42 Engineering expects a developer to know before she starts working on a codebase. We will have different batches for fresh graduates and for experienced developers. A rough sketch of the program for freshers:

  • Programming 101
    • Introduction to Ruby
    • Introduction to Git
    • OO Design Principles
    • OO Patterns
      • Creational
      • Structural
      • Behavioral
    • Programming/Design anit-patterns
  • Web Application Development
    • Working within browsers
      • Introduction to HTML & DOM
      • Introduction to CSS
      • Introduction to Javascript and Prototype based programming
    • Ruby on Rails 101
      • Journey through Rails components
      • TDD with rails
  • Introduction to Agile
    • Agile principles
    • Planning and estimation
    • Importance of Automated Testing and Continuous Integration
    • Pair programming, TDD, Simple Design, Refactoring
    • Basics of XP and Scrum
  • 2 Weeks of Ruby on Rails project development in teams, following all the methodologies and principles mentioned above.

The course structure as you can see is still being finalized, but the guiding principle is simple. Provide opportunity and inspiration to the willing engineers to hone their skills.

Bridging the gap

Lots of potential hackers join the Indian IT industry with big dreams. Due to lack of inspiration and opportunities, they stop caring about programming and become an hourly billable unit in an excel sheet somewhere. We want to show them what real development feels like, enable them with both the tools and the practices to become productive and enjoy coding as we do.

Providing this training is pointless if they don't get to work at places where these skills are appreciated. A number of startups in India are being limited by the shortage of technical talent. Businesses are unable to grow as they struggle to hire talented programmers that can build high quality, maintainable codebases that scale and are easy to change. If their codebases are in good hands, business owners are free to concentrate on the non-technical aspects that are often extremely critical for the success of the business.

We plan to connect developers, who are looking for new challenges, with companies who need and appreciate the value they bring to the table.


Aakash is VP Consulting at C42 Engineering. If you liked this post, please consider...


No virtuous circle, or how India's Silicon Valley is... different

A blog post by me explaining my take on India's startup scene, something which has directly impacted C42 Engineering's business model.