Steve Conover's blog
Edward pointed out the great article by Kevin Matheny, featured in BusinessWeek, on Agile, and our experience on BestBuy Remix.
I'd like to highlight this passage:
Trust is tied closely to how you deal with change. Often, extending trust is hard for businesspeople working on technology projects, because we don’t know how to do the work. We often look to the documentation — requirements, design specifications, and the like — to give us the feeling of control over the outcome. Don’t bother. If you can’t trust your team to deliver, you have the wrong team. Find people you can trust, and then let them do the work. Talk every day, and make sure that the development team has direct access to someone who will be using the product every day after release. For Remix, we’ve never had a formal project plan, never had a requirements-gathering session, never created a requirements document. We chose the right partners, told them what we needed, and got to work. We have control over the outcomes, but we’re not worried about trying to control the details of how we get there.
Of course without trust, any project - "agile" or not - is at risk. But practices typically associated with agile let you go further with trust: everyone is in close communication*, and all levels of the project - from test-driven code written by developers, to regular demos to the client of the latest features - are oriented around fast feedback.
In other words, you the customer trust us in part because what we're doing is visible and tangible to you. If we're going in a direction you didn't intend, or what the team planned a few weeks ago just doesn't seem relevant anymore, we all talk and we correct course.
* for close communication, see Pivotal Tracker
net/http is slow. (and so are libraries that depend on it, like open-uri)
Performance Disclaimer: this ought to matter in your app, measurably, before you do anything about it. If you profile and ruby-prof is showing a bunch of classes like BufferedRead and Timeout at the top of the list, your app qualifies. And in addition if you know that your app is dependent on data transfer over http (let's say you're interacting with a Solr server, and you're storing sizable documents in Solr), you should be aware of the problem.
Otherwise net/http or open-uri might be just fine for you.
The problems with net/http, and benchmarks of ruby http client lbraries are nicely written about in An analysis of Ruby 1.8.x HTTP client performance.
Some good alternatives:
Our findings matched the article referenced above - the alternatives have pros and cons but each was at least 10x faster than net/http for transfers of 50-300k response bodies.
The fastest solution we found was curb, reusing the Curl::Easy object:
require "curb"
curl = Curl::Easy.new
2.times do
curl.url = "http://www.pivotaltracker.com"
curl.perform
puts curl.body_str
end
Here's a good, quick read. It got its start about 10 years ago:
http://www.w3.org/DesignIssues/Principles.html
Topics:
- Simplicity
- Modular Design
- Tolerance ("Be liberal in what you require but conservative in what you do")
- Decentralization
- Test of Independent Invention ("If someone else had already invented your system, would theirs work with yours?")
- Principle of Least Power
When you're heads-down doing Agile or OOP sometimes you find yourself accidentally assuming that certain useful general principles are special to what you practice - when the truth is they're probably not even unique to your discipline, and some Greeks wrote them down around 500 BC.
Craig Newmark: Peer To Patent: government using social networking
"Peer To Patent is Washington's first social networking iniative, using a network of volunteers to help figure out if an invention deserves to be patented. The volunteers, normally scientists and technologies, connect with patent examiners, and like Obama says, this "taps the intelligence" of the American public. "
Google CEO touts green energy shock doctrine
Pressing a theme popular with Barack Obama's tech surrogates, Schmidt also waxed enthusiastic about the power of network technology to create a more transparent and participatory politics. "Government has not embraced, generically, the tools we all use every day," said Schmidt. "It's time." Pointing to the Patent Office's Peer-to-Patent program for crowdsourcing patent application analysis, Schmidt asked "why is that not true of every branch of government?" The same "police of the Internet" who debunked political rumors during the campaign could be turned on key legislative and regulatory issues. "A lot of people care passionately about them," joked Schmidt, "and they obviously have a lot of free time."
Writing good code and writing good English are a strikingly similar endeavors. We should be able to apply writing advice to code - not perfectly, but on the whole.
These are some of my favorites - I welcome more thoughts and citations in the comments:
- Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
- Never use a long word where a short one will do.
- If it is possible to cut a word out, always cut it out.
- Never use the passive where you can use the active.
- Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
- Break any of these rules sooner than say anything outright barbarous.
...
A scrupulous writer in every sentence that he writes will ask himself at least four questions, thus: What am I trying to say? What words will express it? What image or idiom will make it clearer? Is this image fresh enough to have an effect? And he will probably as himself two more: Could I put it more shortly? Have I said anything that is avoidably ugly?
Orwell, "Politics and the English Language" (a brilliant essay)
To write a genuine, familiar, or truly English style is to write as anyone would speak in common conversation and who had a thorough command or choice of words or who could discourse with ease, force, and perspicuity setting aside all pedantic and oratorical flourishes.
As a general rule, run your pen through every other word you have written, you have no idea what vigor it will give to your style
Sydney Smith
Clarity of writing usually follows clarity of thought. So think what you want to say, then say it as simply as possible.
...
(Selected do's and do-not's, summarized)
- Do not be stuffy. Use the language of everyday speech, not that of spokesmen or bureaucrats. Consider rephrasing sentences more pithily and accurately. Avoid, where possible, euphemisms and circumlocutions promoted by interest groups.
- Do not be too pleased with yourself (perhaps akin to Kill Your Darlings)
- Do your best to be lucid. Simple sentences help. Keep complicated constructions and gimmicks to a minimum.
...
Scrupulous writers will also notice that their copy is edited only lightly and is likely to be used. It may even be read.
More resources:
Eric Evans' emphasis on Ubiquitous Language in Domain-Driven Design (book, website, wikipedia) is in the same spirit.
Style guides for writers and journalists are good resources, examples are the Economist Style Guide (online, book) quoted from above, and the Chicago Manual of Style (online, book).
Steven Pinker's The Language Instinct is a great starting point for exploring the connection between cognition and language.
Chapter 17 of Zen and the Art of Motorcycle Maintenance, which merits its own post...