… so the “heart” approach is a way of sidestepping the psychological immune system that normally operates to conserve our current view point, our current stored wisdom.
I’m deriving this view point primarily from:
http://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/0688128165
and
http://www.amazon.com/Wisdom-Paradox-Stronger-Brain-Grows/dp/1592401104
I pay for software, but I won’t pay for software if I’m not sure I’ll use it. MacHeist has allowed me to purchase software that I was curious about, but that I wouldn’t normally buy, because I wouldn’t use them enough to justify the cost. Previous examples are Pixelmator and VectorDesigner; current examples are Acorn and Espresso.
I don’t know how much the developers got from my purchase, but it is more than they would have had otherwise. I don’t know how much they would be willing to pay me to refer them to a friend who was switching to the platform, but they got that too.
So what MacHeist has done is allowed me to pay developers to market for them in return for using their software which I wouldn’t have used (or purchased) otherwise.
Win-win.
I can imagine an engineering team turning to Interaction Design as part of their work turning Product Owner stories/use cases into product. (Ok, I don’t need to imagine this, but I’m going to assume I’m not unique here…)
I can imagine that as you get into the conversations that are part of IxD the Product Owners might feel threatened, because suddenly engineering is asking penetrating questions about who these users really are and what they’re really trying to accomplish. A PO who’s used to getting away with vague descriptions might take this personally, might interpret this either as an attack or as a power grab by engineering. (Ok, I admit that I’m not just imagining this.)
I think engineering is less likely to respond this way to the PO bringing IxD into the process since these questions/issues fall more naturally into the PO domain and less into the engineering domain. The exception are the UI people who might feel like IxD infringes on the creative aspect of their jobs.
Jtf:safariwatir jfredrick$ ruby safariwatir_script.rb
/opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require’: no such file to load — ./safariwatir/../watir/exceptions (LoadError)
from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `require’
from ./safariwatir/scripter.rb:2
from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require’
from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require’
from ./safariwatir.rb:2
from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require’
from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require’
from safariwatir_script.rb:2
Jtf:ostatli jfredrick$ sudo gem install firewatir
Successfully installed xml-simple-1.0.11
Successfully installed rubyforge-1.0.2
Successfully installed hoe-1.8.3
Successfully installed s4t-utils-1.0.4
Successfully installed builder-2.1.2
Successfully installed user-choices-1.1.6
Successfully installed commonwatir-1.6.2
Successfully installed firewatir-1.6.2
8 gems installed
Installing ri documentation for rubyforge-1.0.2…
Installing ri documentation for hoe-1.8.3…
Installing ri documentation for s4t-utils-1.0.4…
Installing ri documentation for builder-2.1.2…
ERROR: While generating documentation for builder-2.1.2
… MESSAGE: Unhandled special: Special: type=17, text=”<!— HI —>”
… RDOC args: —ri —op /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri —title Builder — Easy XML Building —main README —line-numbers —quiet lib CHANGES Rakefile README doc/releases/builder-1.2.4.rdoc doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc
(continuing with the rest of the installation)
Installing ri documentation for user-choices-1.1.6…
Installing ri documentation for commonwatir-1.6.2…
Installing ri documentation for firewatir-1.6.2…
Installing RDoc documentation for rubyforge-1.0.2…
Installing RDoc documentation for hoe-1.8.3…
Installing RDoc documentation for s4t-utils-1.0.4…
Installing RDoc documentation for builder-2.1.2…
Installing RDoc documentation for user-choices-1.1.6…
Installing RDoc documentation for commonwatir-1.6.2…
Installing RDoc documentation for firewatir-1.6.2…
For over a month now I’ve been planning a blog asking for examples of great code, code that is worthy of study. The idea being that programmers could learn from the masters they way practitioners in other disciplines do.
But reading about the “monad tutorial fallacy” makes me wonder if this is viable. Just as you can’t understand how monads are burritos without having struggled with the problem on your own I suspect you can’t grasp the greatness of a piece of code without having struggled with the same (or similar) problem first-hand.
If I’m right the idea of having students read the works of master coders might be a lost cause. However this probably strengthens the case for code reviews. People on the same team do struggle with the same problems, so the best code on the team is certainly worthy of study. It might not be the Great but better to have Good that you can benefit from than Great that you don’t.
I expect that in a project the estimates at first will be inconsistent as the team jells and gets their arms around the problem space and their solution. But over time their estimates will begin to have a kind of consistency to them that make velocity a meaningful tool for estimating throughput & backlog.
If there are context changes within a project I believe you’d go through a settling period where estimates were of limited value, but that after a while a new equilibrium would be established.
I don’t think the velocity before and after the context changes would be comparable, at least not in the general case. If they were in a specific case it would either be an accident or a function of the team normalizing the values.
The team normalizing the values is such a key component that it almost stands by itself for why velocities across projects (with different teams) can’t be compared.
I had offered Newtonian mechanics and flat earth theory as various levels of wrong. Flat earth theory was a late substitution for creationism but it turned out to be a poor one. I had intended to contrast Newtonian mechanics as wrong but a useful approximation, while I was thinking of flat earth as ridiculously wrong and not even useful… except that it is. I use the approximation of a flat earth all the time.
So let me rephrase the question to @marick: Wrong in the way flat earth theory is wrong or in the way creationism is wrong?
package com.jeffreyfredrick.cc;
import org.apache.log4j.Logger;
import org.jdom.Element;
import net.sourceforge.cruisecontrol.LabelIncrementer;
public class AlphaLabelIncrementer implements LabelIncrementer {
private static final Logger LOG = Logger.getLogger(AlphaLabelIncrementer.class);
public String getDefaultLabel() {
return “a”;
}
public String incrementLabel(String oldLabel, Element buildLog) {
if (!isValidLabel(oldLabel)) {
LOG.warn(“old label value of ” + oldLabel + ” is invalid. Returning default label.”);
return getDefaultLabel();
}
char oldChar = oldLabel.charAt(0);
char newChar = (char)((int)oldChar + 1);
return String.valueOf(newChar);
}
public boolean isPreBuildIncrementer() {
return false;
}
public boolean isValidLabel(String label) {
return (label != null && label.length() == 1);
}
}
