###Other stuff###
It suffices to say that Jim has been co-working at a local space for some time now. Where he sees opportunity is in an organization that could take care of the administration - invoicing, taxes, space provisioning - leaving freelancers, small proprietors, and other independent developers free to pursue their business. The organization could be run on the mutual model, where all the “clients” are owners.
I’m intrigued by this idea, but I want to skin a slightly different cat. My experience of co-working has been quite different due to Richmond’s lack of a dedicated space for it. Our group has had to be more ad hoc, using Twitter and Google Groups to spontaneously organize meetings at local coffee shops on an irregular basis. Everything I’ve read on starting a co-working venue stresses the need to build the community first, rather than getting the location and expecting people to come to it.
Building on this idea of community-centric development, where developers working on their own client projects reach out to each other for mutual aid and support, I start to wonder whether the co-working group could not be more. Having worked as an employee for software companies - especially consultancies, agencies, contractors, and the like - it begins to occur to me that what we’re building in the community solves many of the problems that impel developers towards employment in the first place.
After all, while it’s no cakewalk, freelancing in the development world has never been easier. Especially in the emergent technologies such as more dynamic, web-oriented languages and mobile development, work is plentiful. The capital requirements are almost zero, as you probably already own everything you need to get started - an internet connection, a computer, and maybe a phone. It’s all about your ability to deliver, to manage client relationships, and carve out an area of expertise that differentiates you. Plenty of tools exist for managing the invoicing, taxes, and client communication for pennies a day.
Because of the relative ease of going out on your own, we should expect to see an increase in independent developers. The demand is definitely there; while it can be a good deal for us individually, it’s often an extremely good deal for the client. Agencies have so much overhead they need to balance that their rates can be three or four times what we can afford to charge. While we may boost our earnings by eliminating all that overhead, it seems clear to me that, more often than not, the client is the one who benefits the most by the lower costs and decreased commitments that come from piecemeal contracting with independents rather than investing in a full scale relationship with another business.
The danger is not that we cannot compete, but that we become an alternative to wage labor for these clients and that they will treat us as such. Reduced compensation is not the only downside of employment; there’s also the lack of control and the sense of dependency that people feel towards their employer. By having a more flexible contract from which either party can more easily walk away, we get more bargaining leverage to be sure, but that says nothing about the relationship we will have once we agree on a billing rate. Clients can be just as bossy and disrespectful as bosses, and they will often try with independent contractors what they would never dream of trying on a consultancy.
Indie developers get treated like ersatz employees precisely because, often, that’s how we sell ourselves: hired hands to the the client’s bidding. We’re cutting out the staffing agency, perhaps, but we’re certainly not positioning ourselves as serious competitors to agencies who aren’t selling services so much as bundles of expertise. In order to have control over the kind of work we do, in order to build a reputation as a source of solutions and not just a tech odd jobber, we have to be able to compete with the IT firm. But what is a firm / agency / consultancy, after all? It’s just a bunch of people who do what we do, with a few differences.
First, they know where to find each other on a regular basis, and so they can work together as a rule rather than as a special appointment they make with each other. Freelance for a while and you’ll realize this is no small matter. In doing so, they build a rapport, a collective competency that multiplies their individual capabilities. Being able to break problems up into sections and tackle in tandem - or being able to have a manager who can help organize this - increases predictability and, often, quality.
Second, it’s not just their status as a team; it’s the diversity of their skills. Very few agencies only do development; they usually couple it with a hefty dose of design, marketing and strategy acumen, project management, client management, etc. A one stop shop staffed with a team of people all specializing in different parts of the delivery of software can serve as a compelling package deal. Clients are willing to pay three to four times what freelancers will charge just to have all their technology needs taken care of by one vendor.
Third, they don’t have to focus on running the business per se: the bookkeeping, the billing, the facilities management, the recruiting, following up on leads, getting paid. Because the people doing our kind of work are employees, they enter into the employment agreement assuming these details will be taken care of (or that they will focus on these details and not have to do development work). The organization handles mundane concerns that so often bog independents down.
Before we ask how we indies can compete, we should first ask ourselves whether we really want to. I’m not convinced we should position ourselves as direct competitors necessarily. Doing our own bookkeeping and client management may suck sometimes, but it’s awfully grounding; we never lose perspective and get disconnected from the meat and potatoes of how we earn our living. There is a certain confidence and self-reliance from knowing that what you’re building is yours. You’re expanding your skill set beyond being a geek prodigy to being a person who can have an impact in the industry and in the community on your own terms, not some boss’s or accountant’s. If your point is to grow to become an agency, then this article isn’t going to appeal to you anyway, because I think employees suck just as much as employers.
But the facade of a fully integrated, unified, monolithic firm can make freelancers seem quite inadequate. It’s a myth, of course: there’s very little that an organization can bring to bear on a problem independent of the specific individuals involved - specific individuals that can vary in quality, are not always easily replaced when they up and leave, etc. Committing to delivering consistency to clients outside the boundaries of the firm can be dishonest when there’s no consistency within the boundaries of the firm, but we’ve convinced ourselves that’s the myth clients want to hear. That’s why firms place so much emphasis on building their own corporate brand; because it serves as a convenient stand-in for the people who actually do the work but could leave anytime. The brand will never quit, and the client’s relationship is with the brand, not the people.
The myth of the firm works, not because it’s a uniquely superior solution for the client, but rather because a more honest arrangement has not been demonstrated competitive. After all, the biggest strength of a firm is the productive relationships developed between the workers. Funnily enough, this is precisely what we’re building in a co-working community; a place where people know they can go for support, for assistance in an area outside their expertise, for a rapport and feeling of camaraderie. If this is where the agency’s strength lies, there’s no reason independent producers couldn’t come together to build their own teams that are not tied to a brand or a boss but can nevertheless produce client value at least competitive with a firm.
Imagine a non-profit entity organized by independent developers in a town for the purposes of managing a workspace and perhaps administrative staff for our individual businesses. We don’t go into the office because we need to; we go because we want to - because we want the company, we want to compare notes on solutions or commiserate about problems, and we want to see what others are doing. We build the relationships with each other without needing to control each other via employment.
Now some interesting possibilities arise. Imagine if I am trying to sign a client for a project, but they need more development labor than I can provide. Or they need a designer. Well, it just so happens I know some guys I can call in. They may not work “for” me, but we have a rapport, we’ve worked through problems in the past, and I trust them. I know what they bill. I can bring them in and do the work - perhaps as subcontractors, perhaps through an ad hoc entity, perhaps as independent contractors with the client. It doesn’t really matter; what matters is that we’re finding a way to meet a client’s needs outside of growing our own business and hiring people. We’re capturing the strength of the firm without becoming it.
Here are some other possibilities:
We offer training for people who want to get involved in software development, and give them opportunities to exchange their time and energy to learn the skills they’d need to build their own business and perhaps join our group.
We become a destination for clients who, perhaps at first, merely want advice. We place an emphasis on educating them about quality so they can make informed decisions about IT services. By making them better clients who can employ our expertise in a less distorted, more efficient manner, we help the entire industry. And we get great leads.
People who still work for “the man” in I.T. now have another option. They have more leverage in demanding better pay and treatment from their employer, because now they see the alternative. They might even be able to pick up some work from us if they get fired or need to quit. This raises the bar for wage labor and all boats rise.
If some of the above sound like a trade guild or union, then you’re understanding me. But it neither has to necessarily work out like that nor like anything in particular. The precise direction in which any of this would evolve is a secondary concern.
What’s more important to me is that we see the potential and possibilities in the act of striking out on our own. We don’t need to conform to the standards set by a bunch of large, corporatist behemoths who thrive off of inefficiency and mediating between the client and the producer. We don’t have to think of our independence as wage labor by another name. There’s room for real organizational innovation in the business of software development.
By taking initiative in solving our own problems, by meeting our own needs creatively and unconventionally, we might transform this stagnant and conservative industry. Who knows, we might even provide an organizational model for how workers in other industries can better work. Remember: we didn’t stop working for “the man” just to do business like him!
]]>The tests are there but nominal; I’d love to see them fleshed out. I also had some ideas for making it cooler; for example, I keep an array of an object’s descendants in the object, allowing me to hierarchically order objects. This opens up some novel means to simplify how I implement the parent and children accessor. Imagine this:
field :ancestry, type => Array # contains ids of all ancestors including self, already exists
# but instead of a parent_id accessor
def parent_id
ancestry.at(-2) # the parent can be fetched from the ancestry list
end
This also allows all descendants of a given object to be easily fetched - if the id shows up in the ancestry, return it! It’s this kind of out-of-the-box thinking that has really endeared MongoDB to me. I hope you can benefit from this and help me improve it. Or help with greedy. I’d love to get said help at CVREG’s upcoming Why Day hackfest.
]]>Michael at one point talked about the expense of 100% code coverage for tests, instead recommending we test the parts of the code that change the least and are most important. Ugly code in legacy projects has utility, he explained, and untested code is a rational response to churn. Afterwards, Glenn discussed software development in the context of engineering principles from older, more established disciplines like structural engineering, finding areas of similarity, analogy, and abject difference. However, his testing point compared experiments in code to experiments in more physical engineering fields, remarking on how relatively cheap tests are for us. I suppose the common thread I found concerned the emphasis on cost: that what it means for us to do our job well is to do it effectively, and not subordinate our conscience and creativity to a mechanical process.
For some background, I’ve been practicing behavior driven development for a year or two. I love the confidence that testing gives me, independent of the value to the client. Verifying that my code works is fine and all, but what lets me sleep at night is the assurance derived from approaching a problem in a rational, systemic manner. By moving in small chunks and expressing problems in terms I understand well enough to programmatically recreate, I ground myself in a real comprehension of the system I’m building at the most relevant level and stage. I avoid the confusion of jumping ahead, thinking too large scale or minutely, or making unwarranted assumptions that come back to bite.
But I’ve found there are definitely times when testing first is the wrong approach. Remember: testing is supposed to reinforce your understanding of the problem. But what happens when you fundamentally don’t understand it? When you first encounter the project, you don’t necessarily have expectations or any way of identifying what a successful outcome is. Test first is supposed to get you to think about these things, but there’s no substitute for writing and running code.
Experimentation, trial and error, and playing around are important discovery mechanisms that give us the understanding we then apply to more rigorous processes. Spending time writing tests that do nothing but reinforce the fact that you don’t know what you’re doing is stupid. I’ve found that you have to think carefully about what you’re expecting your tests to actually accomplish for you, as you can dig yourself down rabbit holes needlessly by stressing form over function.
Similarly, as Feathers pointed out, even well understood requirements and algorithms often cost more to test than its worth. Code that changes often can cause test churn that burns up effort needlessly. And often we write large swaths of code that, while useful, just isn’t that critical to the success or failure of the project. Given these tensions, 100% coverage may not simply be an unreasonable goal - it may be positively wasteful.
Again, the problem is deeper, as Glenn pointed out in his talk. Historically (and surprisingly in spite of salient warnings as early as the 60’s) “Software Engineering” with capital letters has been biased towards a philosophy of formal, defined process models that demand predictability and reproducibility. Although behavior driven development may seem to encapsulate this philosophy, remember that when we’re dealing with behavior we’re not necessarily realizing mathematical precision at the level many engineers would expect. Accuracy is important in some engineering contexts, but flexibility can sometimes trump it.
A final thought that I consider my unique contribution to this discussion: if you do test first, consider that your tests may be disposable. It’s great that you are using tests to drive the development, and building a test suite imparts tremendous satisfaction as you pile on more and more features. But just because a given test is useful to writing the code doesn’t mean it’s useful for verifying the project’s success. It may in fact be, but that should be a demonstrable standard - don’t let your personal satisfaction detract you from the big picture goal of the project.
100% code coverage is increasingly seen as superfluous because areas of code churn are just a fact of software development. You may find the changes are so targeted and frequent that more exploration and manual play pays off more than working out programmatic unit tests. Also, why wouldn’t your test suite have cruft just like your source code? Perhaps your legacy tests reflect an emphasis on certain requirements that are just too rigid. In that sense, paring down the tests-as-specs is entirely consistent with the project’s interests as it reflects the actual state of the project. Tests out of sync with current requirements are often worse than no tests at all.
Conventions and best practices are no excuse to forget our responsibilities to the client’s budget. The point is not to adopt a rule that tests are no longer important to maintain; rather, avoid blindly following any rule for its own sake, especially when you’re being paid to use your brain. Your job is not to write code; it’s to deliver client value, and that requires careful thought. Depending on the importance of a given section of code, rewriting that unit test may be less useful than scrapping it for the moment - or perhaps focusing on integration tests instead. Always be willing to step outside your comfort zone to better understand the project and realize it’s criteria for success - even if you lose a bit of sleep over it.
]]>Because of the success of Rails, there’s a lot of shitty code out there for you to fix. The harder issue is figuring out why shitty code was delivered, which can be trickier to figure out than you’d think. It can be really difficult to change the course of a project when much more than merely the code is dysfunctional.
Tammer suggested a ton of coping strategies, many of which end up being good practices for most situations. I’m sharing my cursory notes here in case others are interested. Feel free to strike up a conversation in the comments to explore these points. I’ll link to the slides when they become available.
class MembershipStatus < ActiveRecord::Base
if RAILS_ENV == 'test'
def self.[](label)
case label
when :pending
MembershipStatus.new(:id => 1)
when :accepted
MembershipStatus.new(:id => 2)
when :denied
MembershipStatus.new(:id => 3)
when :invited
MembershipStatus.new(:id => 4)
end
end
else
acts_as_enumerated
end
end