I think every programming language (and frameworks too) generates a dominant culture. It might be implicit in the language/tool itself, or it might happen more gradually through self selection. For example, here's how I distinguish three cultures (the boundaries are inherently fuzzy, and I'm aware that this is totally personal opinion, so people are bound to disagree by either raising counter-examples or saying they don't agree, and that's fine). I also have my tongue firmly in my cheek, but I believe there's an element of truth in each statement.
Java - a fascination with flexibility, generally achieved through complexity (and a healthy(?) does of XML). Ten years ago I would have said Java was focussed on solidity and reliability (in the meeting expectations sense), but I think this has changed over time. New functionality is implemented by adding new options. If it doesn't work, it's because you didn't configure it properly.
Rails - a fascination with bright, shiny new toys. Encourages the image of the developer as a person young enough to live in the code, who can deal with either new tools or tools that fundamentally change every three months or so. New functionality is achieved by implementing a new plugin/gem which needs to be compared to all existing alternatives. No solutions is 100% complete because people lose interest first. If it doesn't work, get in there and change the code yourself. [note - I don't comment on Ruby itself as I don't have enough exposure to the non-Rails community]
Seaside - I'm an old-hand in Smalltalk, just learning Seaside. So far I see a fascination with having something that just frackin' works (though it might be heavily engineered). The documentation sucks though, so get into the code. Changes are generally transparent and backwardly compatible. If it doesn't work, you did something wrong - the community is the documentation.
Each of these cultures has strengths and weaknesses. I'm 46 years old (shit, when did that happen), my raw memory isn't as strong as it was, and I don't think as quickly as I used to. But I have a load of experience in developing design models and applications - I want tools that get out of my way and let me build things. Given my Smalltalk experience, Seaside is a great match for me - much better than Rails. If there was the equivalent of "Agile Web Development Using Rails" then it would rock!
In an age when everyone needs to use portfolio theory to manage their software investments, starting low-cost initiatives by the dozen then abandoning the ones that don't work out, Rails is a clear winner over Java. It lets me experiment at low cost, it lets me get something out-the-door quickly. In that environment Java is a set of leg-irons. But the Rails culture thrives when people have enough time and energy to deal with a firehose of changes and alternatives - as an entrepreneur a lot of this is simply waste. One solution might be to standardise on a particular configuration - that seems like a false.optimisation.
Tuesday, July 28, 2009
Tuesday, July 14, 2009
What would you like in a code quality tool?
Although continuous integration has been a huge step forwards for the development community I think that over time we've tended to treat it as a rather large bucket that we could keep tossing things into. Sure, someone should immediately address that method that's too long, but should it really stop the build and the release of the next version if all the tests pass? My feeling is no, it shouldn't.
I think that the agile community could do more to encourage various parallel continuous processes that test different aspects of the application. In particular, we could separate the static analysis of the code quality from the behavioural analysis that we perform with tests, be they unit, integration or functional tests. If we separate the two aspects then we can look to improve them at different rates and in different dimensions. This separation is the motivation behind an idea that Marty Andrews and Simon Harris have been kicking around for a few years (Marty is the author of Roodi and Complexian, and Simon is the author of Simian, so they have a long-running interest in code quality). Cogent is now planning to turn this into a product - something that you can point towards your source code repository and simply unleash.
We don't have a name for the product yet (suggest one if you like), but it will run static analysis tools (like Checkstyle, Simian, Roodi, Reek, Flay) against each revision of your code base so that you can see trends over time, and it will produce warnings when the values of the metrics exceed certain thresholds. The product will be free for open source projects.
We'll start with a simple, web-based version, probably to run over Ruby projects in public Git repositories (because that's low-hanging fruit for us), but we're going to be very community driven. With this in mind we have a survey that will let you influence the development direction, even before we start. If a tool like this is something that interests you, please fill in our product survey. As a bonus, the first 500 people to complete the survey will get unlimited free access to the product in recognition of their contributions.
I think that the agile community could do more to encourage various parallel continuous processes that test different aspects of the application. In particular, we could separate the static analysis of the code quality from the behavioural analysis that we perform with tests, be they unit, integration or functional tests. If we separate the two aspects then we can look to improve them at different rates and in different dimensions. This separation is the motivation behind an idea that Marty Andrews and Simon Harris have been kicking around for a few years (Marty is the author of Roodi and Complexian, and Simon is the author of Simian, so they have a long-running interest in code quality). Cogent is now planning to turn this into a product - something that you can point towards your source code repository and simply unleash.
We don't have a name for the product yet (suggest one if you like), but it will run static analysis tools (like Checkstyle, Simian, Roodi, Reek, Flay) against each revision of your code base so that you can see trends over time, and it will produce warnings when the values of the metrics exceed certain thresholds. The product will be free for open source projects.
We'll start with a simple, web-based version, probably to run over Ruby projects in public Git repositories (because that's low-hanging fruit for us), but we're going to be very community driven. With this in mind we have a survey that will let you influence the development direction, even before we start. If a tool like this is something that interests you, please fill in our product survey. As a bonus, the first 500 people to complete the survey will get unlimited free access to the product in recognition of their contributions.
Cogent plays dress-ups
This is an email that I sent to everyone at Cogent Consulting this morning, reprinted here because I think it demonstrates the values that we're trying to pursue (and some other people seem to agree). The background is that we're having an offsite this weekend and one of the staff has asked everyone to 'dress nicely' because there will be a professional photographer to take some staff shots. Unlike most of our decisions, this wasn't telegraphed or discussed in advance. There was some resistance.
I broke my transparency rule yesterday, and let what was for me a considered decision look somewhat arbitrary and without explanation. So, why have professional photos of the staff?
First, we're going to be doing more and more work for people who don't know us personally, or even by reputation. The pool of work from people who already know us has shrunk, and the team has grown. Neither of those are bad things - from my perspective they're an inevitable part of time passing. What it also means to me is that we need to be a bit more careful/particular about how we present Cogent as a product/service.
Presenting Cogent has lots of aspects. Peter Styles from RedBubble was talking to some people last night while I was on the phone and pointed to me and remarked "these guys can be the Pivotal Labs of Australia". That assessment appeals to my ego, but it's also an interesting guide to projection, promotion and marketing. The Pivotal guys blog a lot, and they produce open source projects - we do some of each, but not as much as we could. I don't put enough emphasis on it myself.
Another aspect of presenting Cogent is making the website look "polished". It's hard to put my finger on what that really means, but we all have websites that give us a "wow" factor, even if we'd come up with quite different results if we listed those sites. It's not a single thing that makes the difference, but I think that one thing is having well-presented, reasonably consistent, photos of the staff. It literally stops the company from being a faceless entity. Hence the professional photographer on the weekend.
If you stop by the TW office you'll see that they make extensive use of real photos of real staff right in their reception - there's a wall with large scale images, not just snapshots. From memory Evan is reclining in a deck chair working on his laptop :-) I'm not proposing something like that right now, but I wouldn't rule it out in future either - I'm proud of the people in the company and I want them to be the face of the company. I don't want everything to be about 'senior management' as it is in lots of places. We may find other places where putting photos of our staff makes sense - for example, tender documents often list staff, and I think having small photos included in a list like that makes it more appealing (I have this strange idea that saying no to even a picture of a person's face is harder than saying no to a piece of text *s*).
Anyway, there's the rationale. If there are people who have personal objections to photos under any circumstances then of course I respect that. If the resistance is because it seems 'corporate' or corny then I'd like you to try to overcome that for just a little while, since I sincerely believe this is helpful.
Steve
I broke my transparency rule yesterday, and let what was for me a considered decision look somewhat arbitrary and without explanation. So, why have professional photos of the staff?
First, we're going to be doing more and more work for people who don't know us personally, or even by reputation. The pool of work from people who already know us has shrunk, and the team has grown. Neither of those are bad things - from my perspective they're an inevitable part of time passing. What it also means to me is that we need to be a bit more careful/particular about how we present Cogent as a product/service.
Presenting Cogent has lots of aspects. Peter Styles from RedBubble was talking to some people last night while I was on the phone and pointed to me and remarked "these guys can be the Pivotal Labs of Australia". That assessment appeals to my ego, but it's also an interesting guide to projection, promotion and marketing. The Pivotal guys blog a lot, and they produce open source projects - we do some of each, but not as much as we could. I don't put enough emphasis on it myself.
Another aspect of presenting Cogent is making the website look "polished". It's hard to put my finger on what that really means, but we all have websites that give us a "wow" factor, even if we'd come up with quite different results if we listed those sites. It's not a single thing that makes the difference, but I think that one thing is having well-presented, reasonably consistent, photos of the staff. It literally stops the company from being a faceless entity. Hence the professional photographer on the weekend.
If you stop by the TW office you'll see that they make extensive use of real photos of real staff right in their reception - there's a wall with large scale images, not just snapshots. From memory Evan is reclining in a deck chair working on his laptop :-) I'm not proposing something like that right now, but I wouldn't rule it out in future either - I'm proud of the people in the company and I want them to be the face of the company. I don't want everything to be about 'senior management' as it is in lots of places. We may find other places where putting photos of our staff makes sense - for example, tender documents often list staff, and I think having small photos included in a list like that makes it more appealing (I have this strange idea that saying no to even a picture of a person's face is harder than saying no to a piece of text *s*).
Anyway, there's the rationale. If there are people who have personal objections to photos under any circumstances then of course I respect that. If the resistance is because it seems 'corporate' or corny then I'd like you to try to overcome that for just a little while, since I sincerely believe this is helpful.
Steve
Subscribe to:
Posts (Atom)
Posts
