On some level it seems to make sense, when building your startup staff, to want your “generals” in place before you start drafting your soldiers. That way plans can be made, hierarchies established, and processes put in place. But, it is precisely because these seem like perfectly responsible and sensible things that so many software start-ups spend so much time and money before they ever ship a product. Ostensibly, the goal of hiring the project managers, business analysts, data architects, and the like is to lay the groundwork and improve the efficiency of the team. The problem is, the efficiency these companies are seeking is squandered in the weeks and often months that it takes for these roles to actually get going at full-steam.

When organizations get top-heavy and the management and analyst ranks swell to outnumber the designers and developers there is cause for concern. The startup would be much better served hiring more developers and designers and let them build software inefficiently for a while. Then they can figure out their work patterns and identify where improvements to the process can be made. I would take 6 months of inefficient software creation over an equal time spent in visioning meetings, “process engineering”, and gantt chart plotting. How about you?

This is interesting: Indian software development firm Wipro is planning to hire 500 programmers in the U.S.

The company has stated that their decision was based on whether they wanted to compete on price or on quality (as well as some other factors - including politics, since defense contracts can typically only be awarded to firms doing the work here in the states).

Last week, Nat Pryce shared some good thoughts (and code examples) on using Builders for test data creation. His comments on how an Object Mother can be painful to maintain really resonated with me and mirrors my own experience.

As he points out, using an Object Mother can really clean up test code, making tests much more readable and straightforward. The downside is that they can end up being brittle or many times the number of methods tends to explode, as minor differences are needed for different test scenarios.

Using Builders also cleans up test code, but can allow for differences in test data without the need for a new method for each scenario.