After 13 years of helping companies of all shapes and sizes design products and applications, I joined C42 Engineering a couple of months ago to start our experience design practice, based in the Bay Area. I’m not sure if the phrase ‘design practice lead’ reflects what I do, but I'll get to that later. As you can imagine, for a young start-up in India that is making significant investments in developing products, it is challenging to support my market salary in the US. So, I chose to earn a variable income, with the optimism of growing our business in the US market, offering services in software design and development.
My decision has been met with a variety of reactions - some positive, and a lot skeptical. For me, this move was the most logical next step, and a no-brainer. The main challenge so far has been explaining its rewards to a husband who is a mergers and acquisitions consultant, and I’ve come out in flying colors on that one. Here’s why I think C42 is going to be an organization of choice for other designers as well:
At C42, the whole is greater than the sum of its parts
"In order to achieve high-quality user experience in a company's offerings, there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design" (quoting Nielsen Norman). I know this is true from having practiced collaborative design in a variety of environments. But, I am yet to see another organization where personal agendas and turf wars have not got in the way of achieving this seamless merging. At best, you might have engineering, product management, and design teams having regular meetings, and more commonly each of them throwing deliverables over the cube to each other. Ultimately, the product suffers, and the user’s experience is compromised. C42 being a small team seeded with talented engineers who aren’t sniffled by silos and roles, is extremely well positioned to deliver products and solutions that are beautifully designed and engineered by a multi-disciplinary team.
At C42, it will be as beautiful as possible, even if it's inside the box
I’ve met several designers with great ideas for product designs, frustrated that those designs just show up in their portfolio, and haven’t made it into the hands of the user. At C42, you will experience the satisfaction and joy of seeing your design ideas get delivered. What’s more impressive is the passion and commitment with which the team writes beautiful code. If you’re a passionate designer, you can relate to what Steve Jobs said about the PC board “I want it to be as beautiful as possible, even if it’s inside the box. A great carpenter isn’t going to use lousy wood for the back of a cabinet, even though nobody’s going to see it.”
C42 Labs is design thinking in action
The empathy with which C42's first product (rubymonk.com) was designed, the extreme collaboration and iterative prototyping that's gone into its releases - is design thinking in action. If you are interested in leading through design, I invite you to see how C42 Labs develops products. If design thinking is more doing than thinking, then, the team does one heck of a lot of design thinking. It provides a solid platform for professional growth and thought leadership in the design community.
So, if you are someone who cares about the user more than your design portfolio, someone who believes that user experience should be second nature to software engineering teams, someone who is committed to making the power of extreme collaboration work in creating great products, you want to talk to us.
Anu is the Practice Lead for User Experience Design at C42 Engineering. If you liked this post, please consider...
While we at C42 continue to debate this topic amongst ourselves, thought I'd share my thoughts, and hear what others have to say. Let us know what you think.
We've got three talks at this years RubyConf India. Here's a quick list - click through for more details.
- "Sandboxing Ruby Code - Lessons from the battlefield," by Tejas Dinkar and Jasim Basheer
- "Clojure is my favourite ruby," by Steven Deobald
- "Testing patterns," by Sidu Ponnappa and Aninda Kundu
We're also happy to be one of the sponsors the event for the second year running.
Most of C42 is flying out to Pune for RubyConf India, so do say hello if you're going to be there.
The reason I haven't written about this before is because in certain circles, this post would be stating the obvious. However, it's become increasing clear to me that in the mad rush to prove that they 'get testing,' most new Ruby/Rails programmers completely miss the real reason TDD is so valuable. So, here goes:
"TDD is not about testing your code. The fact that your code gets tested is a valuable side effect."The hardest part of writing code is keeping all of the moving parts in your head so you know exactly what side-effects the new code you're writing will have on existing code. This is how most bugs crop up. Nobody wants to introduce a bug, but the chain of cause and effect in a non-trivial codebase can be very hard to follow. Everyone runs into this sooner or later, and this has been named "The curse of the gifted programmer" (in a different context, but the principle applies).TDD is a tool which allows you to use your tests to break the code you're working on down into tiny chunks, thereby reducing what you need to hold in your head, in turn reducing the likelihood of you introducing defects and making it easier for you to understand what's going on. The fact that the the test suite thus produced can subsequently be used for regression testing is a very positive and useful side-effect, but a side-effect nonetheless.
A few other conclusions can be derived from this statement:
- Languages and codebases which eschew side-effects and thereby achieve the same goal of reducing the quantity of code programmers need to hold in their heads see decreased or negligible value from TDD.
- If you and your team are smart enough, you don't need TDD because holding code in your head isn't a problem. You know you're this smart when you can consistently hold in your head the cause and effect chain across your entire codebase for any change you or your colleagues make.
- If you can't test drive a particular piece of code, either you know too little about possible solutions, or you have poorly factored code. Consequently, you can use TDD as a sort of canary-in-the-coalmine to figure out which bits of your codebase could be better factored.
If testing was what TDD was about, TDD (test first) and unit testing (test last) would be equivalent. They aren't.