Planned Obsolescence in Software

We strive to create designs that will last. But in doing so, we run the risk of over-engineering: building in so many abstractions at the beginning of a project that it degenerates into unmaintainable code.

What causes these risks, and what can we do about it? If there were a simple answer, everyone would be doing it already. Instead, we have to make do with a few heuristics, practices, and insights into human nature.

Transcript

1. Planned Obsolescence Built to Last, or Build One to Throw Away? OSCON 2013 Baq Haidri • @baqhaidri Ian Dees • @undees
2. Baq making things work at scale
3. discoverable REST APIs http://rest.li/
4. Ian tinkering with hardware and software
5. http://pragprog.com/titles/dhwcr discount code: CucumberIanDees
6. So, planned obsolescence
7. OSCON 2012
8. — Should software makers apply the planned- obsolescence strategy? — Like, a self-destructing Github repo? — More like designing things for the correct lifespan.
9. Computer programs are... machines with far more moving parts than any engine: the parts don’t wear out, but they interact and rub up against one another in ways the programmers themselves cannot predict. —James Gleick
10. Over-engineering
11. Project needs this:
12. ANTLRParser.new
13. Engineer ships this:
14. def create_parser xml = read_ridiculously_long_xml_file config = hash_from_xml(xml) type = config["type"] case type when "ANTLR" then ANTLRParser.new when "yacc" then YACCParser.new else raise "Unknown parser #{type}" end end
15. Why do we do this?
16. We imagine our software will be around forever
17. Life of an Engineer
18. 1. n00b 2. Second-system effect 3. Too clever by half 4. Realism 5. Nirvana
19. 1. n00b
20. 10 PRINT "HELLO WORLD" 20 END
21. Feature spree
22. GPIBDevice::GPIBDevice(int newAddress) : address(newAddress) { // bunch of options code... }
23. GPIBDevice::GPIBDevice(int newAddress, int newSecondary) : address(newAddress), secondary(newSecondary) { // bunch of options code... }
24. GPIBDevice::GPIBDevice(int newAddress, int newSecondary, double newTimeOut, bool txEoi) : address(newAddress), secondary(newSecondary), timeout(ConvertTimeout(newTimeout)), sendEoi(txEoi) { // bunch of options code... }
25. GPIBDevice::GPIBDevice(int newAddress, int newSecondary, double newTimeOut, bool txEoi, bool sendCr, bool sendLf, bool expectCr, bool expectLf, int bufSize, short newId) : address(newAddress), secondary(newSecondary), sendEoi(txEoi), sendReturn(sendCr), sendLinefeed(sendLf), expectReturn(expectCr), expectLinefeed(expectLf), bufferSize(bufSize), id(newId), pBuffer(NULL), receiveLength(0) { // bunch of options code... }
27. The cost [of adding a feature] also includes the addition of an obstacle to future expansion.... You will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web. The trick is to pick the features that don’t fight each other. —John Carmack
28. GPIBDevice::GPIBDevice(GPIBOptions options) { // ... }
29. The right abstraction wasn’t obvious at first
30. What happens when...
31. You are asked to build this
32. But you want to build this!
34. public class Voltron { public Voltron setType(Type type) {} public Voltron setColor(Color color) {} List<Part> getParts() {} public static void main(String[] args) { Voltron v = new Voltron(); v.setColor(YELLOW).setType(LION).render(); } }
35. “Hey, this needs to be more general!”
36. public class Voltron extends Robotron { // ... public static void main(String[] args) { Voltron v = new Voltron(); v.setColor(YELLOW).setType(LION).render(); } }
37. public abstract class Robotron implements Transformable<Robotron> { @Override public Robotron render() { for (Part part : this.getParts()) { part.render(); } return this; } // ... }
38. public interface Transformable<T> extends Renderable<T> { T setType(Type type); T setColor(Color color); List<Part> getParts(); }
39. This flexibility wasn’t a project requirement
40. Good frameworks are extracted, not invented. —David Heinemeier Hansson
41. What about one-offs?
42. This is okay
43. You look back at all the projects you’ve ever been on, and you can’t think of a single piece of code that wasn’t rewritten at least once, maybe half a dozen times, over the years. —Steve Yegge, http://bit.ly/yegge-mystery-3d
44. One-offs teach us to abstract
45. class BrewerTest : public CoffeeTest { public: bool testBrewing() { brewer.brew(); COFFEE_ASSERT(brewer.brewed()); } };
46. class BrewerTest : public CoffeeTest { public: bool testBrewing() { brewer.brew(); COFFEE_ASSERT(brewer.brewed()); } };
47. class BrewerTest : public Test { public: bool testBrewing() { brewer.brew(); ASSERT(brewer.brewed()); } };
48. Don’t be afraid to use this!
49. Or this!
50. Or this!
51. There is one ongoing project, even in one-offs:
52. YOU
54. 2. Second-system effect
55. class CHello : public CHelloBase { public: IPFIX(CLSID_CHello); CHello(IUnknown *pUnk); ~CHello(); HRESULT __stdcall PrintSz(LPWSTR pwszString); private: static int cObjRef; };
56. How engineers measure our self-worth
57. ?
58. Ability to tackle complexity
59. So we invent extra complexity
60. class Adder def add(a, b) space = \ @antlr_parser.curr_node.space_needed do_stuff_to(a, space) do_stuff_to(b, space) result = \ @antlr_parser.curr_node.mkspace(space) result.fill_with(a + b) end end
61. class Adder def add(a, b) space = \ @antlr_parser.curr_node.space_needed do_stuff_to(a, space) do_stuff_to(b, space) result = \ @antlr_parser.curr_node.mkspace(space) result.fill_with(a + b) end end
62. “I can handle it”
63. Anticipate the WTF? factor
64. “Just because I can... should I?”
65. def create_parser xml = read_ridiculously_long_xml_file config = hash_from_xml(xml) type = config["type"] case type when "ANTLR" then ANTLRParser.new when "yacc" then YACCParser.new else raise "Unknown parser #{type}" end end
66. “Would I want to support this?”
67. Because you’re going to!
68. Have the courage to decide provisionally
69. 3. Too clever by half
70. #include <stdio.h> #define S "Hello, World\n" main(){exit(printf(S) == strlen(S) ? 0 : 1);}
72. Over-applying DRY
73. it "converts to Fahrenheit" do zero_c.fahrenheit.must_equal(32.0) end it "converts to Kelvin" do zero_c.kelvin.must_equal(273.0) end
74. it "converts to Fahrenheit" do zero_c.fahrenheit.must_equal(32.0) end it "converts to Kelvin" do zero_c.kelvin.must_equal(273.0) end
76. [["Fahrenheit", 32.0], ["Kelvin", 273.0]].each do |units, expected| it "converts to #{units}" do method = units.downcase.to_sym actual = celsius.send(method) actual.must_equal(expected) end end
78. And if you really have a lot of data...
79. Celsius Fahrenheit Kelvin 0 32 273 100 212 373
80. Use a table!
81. | Celsius | Fahrenheit | Kelvin | | 0 | 32 | 273 | | 100 | 212 | 373 |
82. Choose the right idiom for the environment
83. def first_after(day) @table.find { |m| m.day > day } || no_meas end
84. measurement* found = find_if(table, table + size, compose1( // f(g(pair)), where: bind2nd(greater<int>(), day), // f(num) is "num > day?" select1st<measurement>())); // g(pair) is "pair.first" return found ? *found : no_meas;
86. Fear of the for loop
87. for (int i = 0; i < size; ++i) { if (table[i].first > day) { return table[i]; } } return no_meas;
88. 4. Realism
89. echo "Hello, world."
91. We make discoveries, we autotune
92. A generic probabilistic metaheuristic for the global optimization problem of locating a good approximation to the global optimum of a given function in a large search space. —http://en.wikipedia.org/wiki/Simulated_annealing
93. Interfaces don’t require multiple implementations
94. class WORNStorage { public: void write(const char* k, void* v) { // poke hardware registers } };
95. int answer = 42; storage->write("answer", &answer);
96. class Storable { public: virtual ~Storable() {} virtual void write(const char* k, void* v) = 0; }; class WORNStorage : public Storable { public: virtual void write(const char* k, void* v) { // poke hardware registers } };
97. Testability
98. class FakeStorage : public Storable { public: virtual void write(const char* k, void* v) { // DO NOTHING! } }; FakeStorage fake; someFunctionThatStores(fake);
99. Convenience
100. Storable* getStorableFromSomewhere() { return new WORNStorage(); }
101. Conway’s Law and how to use it to your advantage
102. Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations. —Melvin Conway
103. “We’re screwed. The design is going to be bureaucratic and dysfunctional, just like our team.” The Pessimist:
104. The Opportunist: “Sweet. If we organize the team like so, the design will naturally fall out the way we want it to.”
105. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. —Linus Torvalds
106. Don’t solve organizational problems with technical solutions
107. Know your needs
108. Chances are, someone has already done it
109. If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. —Bob Scheifler and Jim Gettys
110. class Project < ActiveRecord::Base has_many :documents end class Document < ActiveRecord::Base belongs_to :project end
111. get '/' do haml :index end get '/projects/:id' do @project = Project.find params[:id] haml :project end
112. @@index %ul - Project.all.each do |pj| %li %a{:href => "/projects/#{pj.id}"} = pj.name @@project - @project.documents.each do |d| %li= d.title
113. This was not “built to last”
114. ...but it did anyway!
115. I LOVE IT WHEN A PLAN COMES TOGETHER
116. 5. Nirvana
118. All the universal truths:
119. Chicken sexing
120. Chicken sexing The experts had no idea how they had acquired their skills in the first place, or how to transmit those skills to others. —Richard Horsey
121. Chicken sexing We require training, or a great deal of detailed observation, in order for us to notice the relevant features, and thereby allow our unconscious mechanisms to acquire the diagnostic cues —Richard Horsey
122. When to abstract?
123. 1. You know in advance e.g., multiple protocols
124. 2. You’re writing a library but what % of your projects are libraries?
125. What makes a good abstraction?
126. We control complexity by building abstractions that hide details when appropriate. —Harold Abelson and Gerald Sussman
127. Hadoop
128. public interface Mapper<K1, V1, K2, V2> /* ... */ { void map(K1 key, V1 value, OutputCollector<K2, V2> output, Reporter reporter) throws IOException; }
129. If you need something once, build it. If you need something twice, pay attention. If you need it a third time, abstract it. —Derick Bailey
130. Fundamentals
131. More! https://github.com/undees/oscon @baqhaidri @undees
133. http://i.lvme.me/hvs3fc1.jpg http://www.flickr.com/photos/trialsanderrors/2741360422 http://commons.wikimedia.org/wiki/ File:Colosseum_Colosseo_Coliseum_(8082864097).jpg http://commons.wikimedia.org/wiki/File:Green_field.jpg http://picardfacepalm.com/ http://www.greenandgoldrugby.co.za/plan-a/ http://commons.wikimedia.org/wiki/File:Bitcoin.png http://www.wpclipart.com/computer/keyboard_keys/special_keys/ computer_key_Delete.png.html http://www.flickr.com/photos/72787861@N00/5981733915 http://www.flickr.com/photos/tjfaust/4452365182/ http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html http://origin-ars.els-cdn.com/content/image/1-s2.0-S0360835201000213-gr5.gif http://upload.wikimedia.org/wikipedia/commons/f/fc/Slide_in_Parque.jpg http://img.archiexpo.com/images_ae/photo-g/large-water-slide-for-aquatic- parks-64440-3624991.jpg http://www.break.com/surfacevideo/stuart-smalley-michael-jordan-snl/family- off/ http://twistedsifter.com/2012/04/50-animated-gifs-for-every-situation-ever/