tag:blogger.com,1999:blog-108963912024-03-14T03:18:42.715+00:00Johnno's NoseA blog about me and my development journey.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.comBlogger58125tag:blogger.com,1999:blog-10896391.post-9116742453545222382013-02-08T00:08:00.000+00:002013-02-08T00:08:35.572+00:00Developers are losing their SQL powersToday on twitter Chris Hey asked:<br />
<br />
<table><tbody>
<tr><td height="52" width="52"><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA0CAYAAADFeBvrAAAVWUlEQVRogd2aeZRedZnnP7/l3vsutS9ZK/tS2UhIJAQiu2gLSIPNCHhcGIeZY7u07UDTja2jOO0C0t1i24qCtCBbQLBdOhGEBERkCyEJwSKEJUtVttrrrap3ub9t/nirAsEOlE6f02fmOef9o6p+v/s+3+f5PustEULg/yeR/9kK/EfLUYA6OjpO6e/vf8w5NwoEIFQqlQAEP/YznkDFBxzB2bEz5dFg05HgvQ0egnVjZ3HhhY5tYbBUCKmrBIsLKS6k2GC9C9774Hw5VNxI8I7gsMEyEqASbMUFXPV7y5TDuD7jH+fc6MDAwG86OjpOeSMGMU657du3n7J06dIHtNZ5AGMMURQdOegxb0AfKNsSWmcxqSerMxw63M+257eRy0dsfe4pRob7Geob4sknt1Bb38zxi9qJa7L8auMm1p78Tq666m9orm9G5xTOg5JQSsskcaZqtdShdYRJU6JMfEyPWGtHd+3a9d4lS5Y8fhSgQqHwVF1d3RpjDEoppKyq773HWovWGiklxhiQAqE0AJXRUbZu2ca3//4bDBb6SbKCj33kT1kwZxrZSDBz5mw2PfI4TVMisrl69nT1cv/9D5OJG5nUMp3OQ4PoKMdXr72K1taZeMCkkMSAN4DEG4VMjk2zQqHwdF1d3UlHAXLOVZRSR0zhnEMI8TqwMX6aFCINzzy7g6effpSDnTtpm9LA+y9dS+vkqex6cReTmltoaagHa6rGSDJgYtCi+hBbwVpD6gz7DnZz+10/pveQ4NIPfYwT1pxCvrYWZwxKgkSBkHj8EV3eLCGEVAiRHAWIKi9RSgFQLpfJZDKM009FAWcCUaTZ8POf850b/5H5c6Ywd/ZU5syYRl0uom3mLOYvWIgplVAhIAX4AAhJxVcp7L3Fe0scKRARXQf62Ly1g5de7CRXV8dLu/dy2uln845Vq1m4cBHWWqTW4D3AMUEB4vcAjXESKeWRi+PAHJaDnfu59fvfo6FR88lPf5S+vh5+ev8D7Nyxm30HBuntP8g555zKX//1JygVDiLw6ChLaiEWGhc8EkHwhjiKGCkavvGPN7Ova5BlyxbjcCT5PHfe/WMGB4bZuPERpkyfBlqivZoQoCN/tdYeueCcAyBNU5IkwTnHl67+X1x47tnU1KR8+rP/gyefeJbvfPdeTjvrYmzSyue++EXuvGcdFZOydcsWsrlaEhmjnSYjEqS0SOER0qMiCZFmf08fk9vmcuu6f+WSyy4n3zCNz17xBe6+427efdap/NM3v0bnnteIiBBCIITAj3nqmKje6CHvqzwdv+S9R2vNgw8+yL13/pDrv/FZgu/G24hbb/s1n/jM/yauiwnCIKhmxPJoP9+94Wv85cc/TCJTnDdorQnWIXN1uHIFY1MyNfV889u3cMEHPoFKWjlw6BVcKqjJ1rB8yRx+9cA9SOVZv+FRPvnpq1m4aMHrSgsxAco5H1AB6z1SRqQVQxwJntv8BD++906u+dLlxFKgdI7Nm1/kpT0FLvrAR3nk4YcY7O6i4PoopYoVx53I7l17mDNzmLNOPY10pICSEUrFPPTwJhYtWcyM2TMwxvCNa79NtqaZuvpmkliTq4PRYkpfb2BwcJCTT1nKyWvewZc+fx2f+7t/YHLrJPAS70AqQJbxKJyPiGQVkB6H5wU4YxGqeiETRTyw4Rd88Qt/yVe+cjXZTC0jvd3U5AQNtTFbnn2YwcJBWptqWbp8BpOTqZQMHOztpOPph1i58AwwAqkzOAGCEebOa+eudT/nokvPZf6SZTRMaWXViatZffJytHMgRnFWouJp/MWff4pcZgH1DQkrV8zjbz/3RW75wU0YZ8YSl8SaDFJ5IlkCshwFSEpJCBo1FlXPPbOZu3/0A9bd8X1aJ2VIB0aoyWTBO+bPnkFEmXPOXsO89vnghoEYbwzZw4PMmN3KgvntmEoJpSTeWFKdMG/5Cvi39fQP9IEr8f7zzuPWH63DmzILZ88mij0hCB7ZeAerjlvEaWtPZLSvi8s+8l/Y130rD/7yAd79nvfigsUGQxwl4CXWeHT0phjy3geQhOC4687beGzjek5as5jLP3YprjQANkbFElepIKIse7p6uOf+n7L6HStomz6FvqEC+7q66Oo8wIUXXsiCRW3gU4JJ8d6jXA2HD3fx2p7XOPnMMzGFAkopDh8eYuOmpygWi1g3AsCstnmceeapJBkLoYJK6hgcHuJrX78ZnbRw+cf/nDnzZuNtQMux0infFEPWpkHrGO/hhhu+wtRWzeqV7cxtm4Zw1cKK8CitsRa0rqG7f5Df/vY3DI8UyGWyzJw5jUWLF1DX0MBdt/8MqWDuvFm0ttTRmKlFaOgfGuK2W9dxxf/8DDV1ARErhM5iRwwBQ6RiUDlssYhUjhACxngy+Qz7Ovfy0GOb6R/UXHX1lzEpCGnRUh8BdIRyQgis9WgtmTt3Ltuee4T5c6cz0mLI6ixSBZTSGFOptkCuQH0tvP/icyE4CHkQIxAMT29+hsJILX/y3gt54Xfb2bOvm6Lfi5Kaxx97hHPfczp1zU240jAYg/X9CJ1DK0VaKSFIq7VQCUAQBKAkXkAmyZHPJ6SpRamAEOqoVHekDikV4X2K95bzzruIk096H9df/0MOdheIGvIED8VisVrtgyVSoHD44jDl4QFMoR83WIGypC5fw0CpwKs9rzF54SwWnLCWlilzUXGextZJdHZ1sfW5bSihkCEmEk1IkVAe9WiZJ9JJ1WjWU0oNujbPTzds4u//aR0HD8OfXfQR4jiAcEgZSNPXAR3xEA7iWFV7Jp/w7rMvYOa0dn6x/mayNYaWXAu5mjq8TRFe4yoerbJUyoYoqoXMKL6coIxm8cKZ1OWbeHn3Frr2FsHkmdpSz4xpinNOvpjrr/sudaefBhlDyRSBOiI3QrY2C6YCweODwnlFtnkyTz3+G367uZMb/nkdSoHzjjR1xDpT1Tvz72Q5VAlrExASqcHblNYp9bzw/CvUZDPYconzLziTGTNmklZGyWZirHFoGVAiQCWHTwK4FAowffIkpredQyUnUD5AanFKw+FhLr7kfOa2T8ePlCCTJ2sCQWmcMcig8S4GKZFxyv33rGPD+q3Esebpxzdx0mlnIKVCaFXll+cImKMLKy6AwlhPJCVIx+WXXcLFF53HSztfYHi0wFCf4Utf/gT5mhpKQ6NkkhQhctiSQUYCL8EFQYLA2RJOB6QB7QVeVePUJAoRJDLIahyXUoQWhFCDVyMEJMYrsk21PPLAozy66bfMmjOJ0VKGx57czNeuu4G589sJFoQIKKVwDpR6Uy+XlgXgkMLhAzz261/TOqmOHb/bTHNLIyuOP4E57Q1cecVXePaZrWRbwHlBpVJEaIkUCc4GhHQ46SDKEcghotyYtWOwkko5oFB4bxkNJUQ+i5ERIeonTUHX5IjrBL9c/0tuufVm/tvlF7Nq2UkkGY81I/zqwQ2IsdZMjSUE9Ya8cARQnHl9oJMKNm58GNB4H/H9m/6FSa2tXPqBDzO1LaVj56Pc/K0fUi7FJLVTEVHAmxG8gNhGOAPKGxJnsFpRiWsomQiRz1EbRUjrCEaQC3kKpRGcL4KIyU6ZxI6tO7j+69dSLu1h1aq51NY0s/mZbWzdup3ly4+nt6cfKfWRZjpN02oCGI+ca665pko4X74m+BiQSOkJ3rN39wEef/wZli5ZwrLFM/nZT+7nXe9aynkXnkClPMBP7l9PX88wbbNmkTTXE0mJL5erFhQC7wK+UiISBkSKEwFbKCFlhA4CYQNJbS06ztHbV+G+H93LSy89wyUfPJ41p7ZTHDJs2vQc9ZPreeXlQ+RyzZx62ruZNWtedZ4CAm5spJBfPiqGjB0Nkc5jDejIYJ1DkaH3cDc3/eDbbFy/gc9/9WTedfYqBnp6aWzKMFoqs/GhF3i5QzF13izWtq9k9uJl4Dwm9hhSckFWM5cQhFjjhQYnUamgMjxKV89+ntjyFPs7X+DMM5azZm0babkb6yJy9bO54spvYYrLOWnNCVxw4QfI1dYjBTjnURK88EgpAPXmAc8F58ZacymRQKlUIZtNIMCjv97AQw/ex4lrHRecv5q0ZNEqhhAxUhpk65bD7NzVTdqraZw5m2lTm5mSy1OOI5zXKGMp+SK2v5/uUone/iF8qUiaK7DmuNm844QWtNZYI0jytTy/o4N71r3AkvYLueRDl6GDAh0RgDS1JLEeo9qRADoakHcEqcyYtyKUBoElNSmRzuEFlEcsd9xyE709j/D+ixayZEkbQlYLbi5qZDA3SrTvEC91a2688sc07PIMrK3lvAtXEaTjUJfkyWv/laYTp/BXN17G5KZRyg111I3WQ+xBjLL9d3v45fr9+HQJF118Ge2L5+AcSGkRUmO9Q0qFHI8bJ0DI3+/lGBvB3yyvU3Kso/WCvbu7uOfuG9HRq5x/wULaF00FIxnprxBPzvG7l/t47NL7aCsWaL3zTzj5+HciGaBnuMBPzr+X8sAo5/3sg8yfORsV+gjDFR7esZcnH99PLlrB+87/7yxaNAfrLEoJvOfIruMt5Ohe7pinhCCEQBx5go8QAmbNncLVn/86z2/pYN3tN1LX/AqnnNXC6vlzAE/HEzuYNdBHx9wW1s6YSRjsRJQlmZZ6+mfUsnBvgWc3HqL9w42su/9Ftr8saJ++ho9e/Hlmz51JEOBIkdogSFDybdU8IhM6KYQArxHSYIxHyoSygeNOWMRxJ3yLp57Yxq82/IKfDf+Gz3zkeA50dDO4O6L53CamNjVhlMS6InmVZ/Lyaey663nadnfyD7f1oEpn8bdf+BS1smpjYwMoh5YagcakAi1BTBDTxKEjCF4QRRCwaKUwvlpIV689jpWrVnHlVZdwqGQQdQdYdt8hHtrYxA9u2MDwgQEqSY4Z7bX0iP2U/6bCbl3gfUvb2b2zlmxkKJVLxHGMjhUBSaXiiCNFFDvA8Mb25q1k4st66RFC41yMcwZNIEYRKjEaePHFF1mxKGb+ytl0Hu7muOMqNG/upOmfd7L8pyln3NdN35XPc7Djcf7u6yUG7V5mTZ7Bzq5N6FJENqlDiAyhajqSJBrbQAWCn7iab5sUxsXjqokkSAgQAgiZgofgYm6/8ybmLnyVl5/ezaFvbifNO94bN1HfqChXUiLqCBnHS0NDvCjKFA55ZnyyjXhKC6tXf5WVyxcAHiHG1dDVdb8ba23+3UXP0VjGbk0QuVcgPZ4KQkoEEc4JlAKhSvQO7eW19U8y+fbX+PDsOWSMYG8cKJUMSiaMUCAUNct0IwtDBT03y/P39HHzpE6mT32VVSvmYoxD64QQIASHUgKlHT54JG+x3H6DTNiXQlqcC0eaULBIVV0h9Q1K7vvJv9F27yCnz2mlq5JjpytinEP4hKIq45SgEU2fdFhhSSmypkZz2o4CHc9uBTSSBBFAClCymqa9jyYM5g8CRNBYpQBTnW6DxtgKQsC2Hc9wyqs9nDGlgWEy1JhR6pBo4XHaoYmJrKKoFVmrEElCJfUME/OemW307txMEVDe44THCiAEAhIpqI7g/+GAeEOT4QUhgFYKIWDXc8+xWtXgpMdVUtLEY3ISWbFY4YiMpc4HTChTjlJsqO7PSzi0h4Z9QxRKBVCSEAJVPGECYfN/CQiAUO00AORYcdi9+RkaazTSBWIRIZxDVRGDD5RjQUEGvLcoCcpaNIGMUNTEGUxPD/v3dYKqApGM177xBPHW++w/GlAIwPiWRXhCCAyNjJLu3cuk2izdpoRWERkL5XKKl4pGk9CY5qiLGmjyCYlXKBFjCaQ+oCJNramw75XXQIy1WiGAEGMfT3jrBHyUTLywCpC+aoPgIQgHQrN//35yvb1EDXVkZEzFOopRoFnX0mVGeSw9TONIDUZLsmEQHdWwNNeA8p5h6YgwTAue7tf2VGvQWKt1jIX828qEPRSovgdFgDfVeiEQdHUdoLE4Sl7lGHUpkXU0JbX0eEPkHc0yx3fUIE9WBhgUHisC3lWLRo2IUQFqFRS6DgAeJapxNJ4IAnK8kZ6QTNhDgYAIouopKbEioAIcPHSIFgRGKhqtpKINQ6aMNp5pUYamsmBh+0JO6erlrCQwGgTBOIrCkiFGuUBdnDC0/xDVnYbEI7BABPjgUciJFFbgD6lDb3ii0FWuO+sZHBykVghGg6csU4ggFZa8iinIIs+6bqYtXERJlBgOo4z4UYSzJDpiJBiGgiefz1Ps68dUKlWlpBxbPb8+vkxUJk45B0F4wGBkIC5lCCpQ6X+ZSimmEYuOJUrkyekGipElrzMMy4RZyxdjraHRtKJ0TFqrqLWa2iShNQiSSpG+1/bS13OYogh4Z0hC9Tu1UKTBva1+4zLx1keBdwElqdaWjGaoe4i9vWV6li+kq2sf7amlXhco4mgMikMy5oBUfPCsd3HXHd/l+Y695LMGE3l6K4JOK+jP1VNob2fh1Hnccsd9fPxTnySXqyV48LL6TjaSbzvc/eGAYHxqFGgshwd6ue7a67jkgx9n1rKlbNvSwcFNj/HCyAGKvkTjkCerEnqHu1k2dSr++Hfy3AKHSjKkQyM0t07FtU1l1qIVLFm5kmkxbNq0kdu+dyt/dcVfgILUWLJRjPceceyXxX8cIIEnOLABIhHTuXc3NVNaOP3E5RwehtNPW0xy+nEYoOjBluBA12G2/8sNpGGEOW0LETVNnHvBRdTkqjU3o8GmFXx5mD5qaWlqYVt3L0ioeEsmignOI9UfNz6YtwLoKSNtTCoksQewXHfLjQy8epg50xfQn3PI0epqd3DkAChBU6aes848hZVrlzJSSrnnvl/w6s7dOKXI5WOayBLl6xhxksJwN1Fa4aOXfYhp82YSfErGKxAKJ+BtMI0nxaP+k+SwUmrSsW5UKJLYHEaDL3sSKUljS2fnPg73DOJ6DtDY1EausYmG1gyZTEyiG1BQfUFmwWWqs01/90H6B/roHylQGElprmmiubmRmdNmkEqD05KYgLISpMTLt85ezrlupdRkoJoWQwiUy+Xvee9NOIa4YENITUhDCKb6ixCCDWmohNGQhlBOQ3AhlNLxGzZUggvFYEMINpRDCMaYUE5LwYQQrAuhZKrPMmNngrEhhBDKIQSbmhBcCMbZY6kUQgjBe2/K5fL3xnG8kXLTnXM/BFYqpRp+j36m6lTrDVqC856ARIcIjGU0AzEQOQ8KKt6T+BgqFpuPqQD5ioPEYZ1HhwxegAwOG8q4KEOUeoJQiEgiDdXnSEeCH2fUUTRzzg0CW5VSHwP2H0W5cVDAfwVWMNGtxH+elIDtwK2MgYHfB/T/vPwf1/3t48vjXtEAAAAASUVORK5CYII=" /></td><td><b>EarlOfTwirl</b><br />Are devs losing the skill of writing good database queries and operations because of the rise in the use of ORMs? Undecided so far..discuss?<br /><a href="https://twitter.com/johnnonolan/status/299626183581106176">07/02/2013 09:11</a></td></tr>
</tbody></table>
<br />
My answer doesn't fit into 140 chars so I'm going to inflict a rare blog post on you.<br />
<h3>
</h3>
<h3>
<span style="font-size: small;">The evolution of programming (in my myopic lifetime):</span></h3>
<h4>
<span style="font-size: large;"><span style="font-size: small;">Rapid Application Development</span><span style="font-size: large;"><span style="font-size: small;"> </span></span></span></h4>
When I was a nipper RAD seemed to be all the rage. Visual Basic & Delphi were the kings in the world of small to medium business and their developers were knocking up simple interfaces on top of simple databases such as Paradox, dBase and the JET engine. Typically database design was very simple in these applications in db theory terms many of these application started off with a <a href="http://en.wikipedia.org/wiki/Universal_relation_assumption" target="_blank">Universal relation</a> and when necessary the applications tended to have a few more tables. Some of the tooling that I experienced helped you glue these queries together producing some suspicious SQL. (And in many dialects ANSI-92 incompatible). <br />
<br />
It's probably worth noting at this stage that the whole point of RAD was to rapidly develop applications. Tooling allowed developers to put together GUIs very quickly and these GUIs were a lot of the time just an interface over the data tables they supported. <br />
<br />
As some of these business became more mature the more requirements for the application grew and so therefore so did the number of entities in datastore. <br />
<h4>
The rise of the enterprise db</h4>
There began a new era. As SQL databases became more popular and many applications stored their data in the same databases (or very similar/replicated distributed dbs) and data became a central part of small to medium businesses's strategy, more questions were asked of the data. In applications and in the relatively new area of Business Intelligence. The developer of this day was asked to do a lot more with asking the database. In addition stored procedures were popular and a lot of business logic was put in there. Data was king and this was the golden of SQL. RDBMS's were begining to look invincible.<br />
<h4>
The fall</h4>
It seems from my point of view at least that not much has come out of RDBMSs in comparision with the application development space. App devs have had to evolve from desktop to web, learn testing, go functional, go dynamic, get SOLID and have had to start testing their own work. In addition to all the tooling changes there was another look at design. A lot of previous systems were developed from a data driven perspective. Now the thinking was to design a system from a domain driven perspective. Databases suddenly became an implementation detail (and a very expensive one in Oracle's case).<br />
<h4>
So about queries</h4>
So what does this little history lesson tell us? Well in the RAD days data and DBs were forming for small to medium orgs. Queries were simple typically as the systems were tightly coupled to UIs and as the whole flipping db was in 1 table. The majority of developers only needed to user very simple SQL. Then RDBMSs became more prevalent and SQL became more popular so geralists had to learn more complicated SQL. As more data was stored in our DBs we had to get smarted with out SQL and learn about optimization too. To get by you needed to know more. Now we are in an age that we are questioning that data should even be stored in an RDBMs there is less motivation for developers to learn SQL in depth.<br />
<br />
I think this is a good thing. Application programming is becoming more diverse why learn about SQL if you are say a mobile dev or a front end dev or a game dev? Our industry is demanding more diversity so why not embrace it?<br />
<br />
<h4>
</h4>
<br />
<br />
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-60050020814159722722012-11-16T20:58:00.000+00:002012-11-16T21:15:07.134+00:00Jamming with professionals<br />
So I just watched this: <a href="http://www.sciencedump.com/content/music-language">http://www.sciencedump.com/content/music-language</a> (5 mins long - don't worry which uses the metaphor of music being a language. The video talks about how many musicians "can only be learned by following a strict regiment under the strict tutelage of a skilled teacher." and that with with learning spoken natural language that you are encouraged to make mistakes. It's argument that this model is wrong.<br />
<br />
- Learning is not something you are sent to do just a few times a week.<br />
- The people you speak to are not just beginners. They are proficient.<br />
- that if we are only aloud to speak with beginners we will take much longer to speak like an adult.<br />
<br />
And that we should learn to embrace mistakes. That we should learn to encourage beginners to play and with accomplished musicians on a daily basis. And that "music works best when we have something to say." as well as that too many rules can slow down learning.<br />
<br />
How does this compare with learning our craft? Many new working programmers are not allowed to be in an environment where they can make mistakes. Most of the time we are always 'in concert'. By the nature of those developers being paid to provide a professional service the majority will only ever end up sounding like band in the school play.<br />
<br />
There are others who hack at home. These are the musicians that play without fear. They will make mistakes but learn but can also fall in to the trap having one way to do things. Without jamming with professionals how can the enthusiastic hacker know their weak points? Will they only be able to play one tune?<br />
<br />
I guess the solution is that we need to have time & space to make our mistakes with mentored supervision. Now I know that there are some companies that promote this & with the advent of code dojo's, hackathons and <a href="http://xpmanchester.wordpress.com/2012/11/08/global-coderetreat-8th-december-2012/" target="_blank">code retreats</a> we are being give a change to make mistakes. I just wish that I knew that when I was learning to play.<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/3yRMbH36HRE?feature=player_embedded' frameborder='0'></iframe></div>
<br />Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-71242016961860689982012-10-13T23:05:00.000+00:002012-10-15T22:25:51.076+00:00much chin stroking at ddd northIt seems like only yesterday that I was sharing stories and having drinks in the bar at Sunderland AFC after the original DDDNorth but somehow 12 months has passed and all of a sudden its DDD time again. This time the organisers moved the venue to Bradford in attempt to make the event closer to my house. So thanks for that.<br />
<br />
The venue was the Bradford University's beautiful School of Management situated just outside the city centre. Registration was a little chaotic but after a quick reorganisation everyone was in and ready.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-beI4z7-WGW8/UHyNRRzMRqI/AAAAAAAAALQ/ZU69gd6xrT8/s1600/photo(3).jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://1.bp.blogspot.com/-beI4z7-WGW8/UHyNRRzMRqI/AAAAAAAAALQ/ZU69gd6xrT8/s1600/photo(3).jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Stunning Venue.</td></tr>
</tbody></table>
<br />
<br />
The venue hosted 4 separate rooms for talks. Unfortunately I've not worked out how to fork myself so I'll take you though the ones I attended.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-5Bfyl6K34ec/UHyJnwI6VbI/AAAAAAAAALA/BcWlq4S4-q4/s1600/crowd.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://2.bp.blogspot.com/-5Bfyl6K34ec/UHyJnwI6VbI/AAAAAAAAALA/BcWlq4S4-q4/s1600/crowd.jpg" height="320" width="240" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">DDDNorth devs watching a session.</td></tr>
</tbody></table>
<br />
<h4>
10 practices that made me the developer I am today - Gary Shutler</h4>
Before we ask the obvious question of do we want to be the developer Gary is today, it's worth pointing out Gary had aimed this session at developers new to the industry. What followed was a walk through of tips of how to really go from Joe average to a great developer. Most of the advice was sound (especially be diverse, and be responsible for your own training) but there was some controversy when Gary rated code reviews but didn't rate pairing. (note: very simplified interpretation). Gary's beard was immaculately groomed.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-VIOjJTDKKLc/UHyHkyP35vI/AAAAAAAAAKg/GuBMhHxG-Ww/s1600/X%252BFactor%252B-%252BRylan.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://3.bp.blogspot.com/-VIOjJTDKKLc/UHyHkyP35vI/AAAAAAAAAKg/GuBMhHxG-Ww/s1600/X%252BFactor%252B-%252BRylan.jpg" height="212" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Gary gave some great advice.</td></tr>
</tbody></table>
<br />
<h4>
Async C# 5.0 - Patterns for Real world user - Liam Westley</h4>
<div>
Technically my favourite session. Liam took us through the <a href="http://www.microsoft.com/en-us/download/details.aspx?id=19957" target="_blank">Task Asynchronous Pattern</a> white paper. Async is Microsoft's latest attempt to make doing more than one thing at once easy. What Liam does really well is slip from slides to code whilst maintaining an interesting patter. His test application was a simple mp3 organiser & player which give some great audio cues as to when things were done. This was definitely a session that I came out of eager to try new things. </div>
<div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-qlxbBWXGHtY/UHyHslUtviI/AAAAAAAAAKw/xjTMoeE8rWw/s1600/photo%25281%2529.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://3.bp.blogspot.com/-qlxbBWXGHtY/UHyHslUtviI/AAAAAAAAAKw/xjTMoeE8rWw/s1600/photo%25281%2529.jpg" height="320" width="240" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Liam's was a fascinating session.</td></tr>
</tbody></table>
<br /></div>
<h4>
Look Ma! No Frameworks - Gemma Cameron</h4>
<div>
Gemma's BDD message was that you don't need any stinking framework to do BDD. Forget about the tools and just have the conversations. She showed by the help of the audience how you could write meaningful test code with out having to be constrained by a frame works language. We had a live kata and some interesting discussion with good points raised by the grizzly looking Ian Cooper.</div>
<div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-ghcGR_tKfB8/UHyHqH4O0oI/AAAAAAAAAKo/0VcyMUQROHY/s1600/brian-blessed-03.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://3.bp.blogspot.com/-ghcGR_tKfB8/UHyHqH4O0oI/AAAAAAAAAKo/0VcyMUQROHY/s1600/brian-blessed-03.jpg" height="230" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Gemma's interactive session was thought provoking</td></tr>
</tbody></table>
</div>
<h4>
Websockets and SignalR - Chris Alcock</h4>
<div>
I've seen this talk before and somehow managed to be in here again. What I love about Chris is that he manages to pack in a tremendous amount of information in to an hour. SignalR and websockets on the front of it are powerful tools.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-hIxDsoziKTc/UHyHxACy1yI/AAAAAAAAAK4/Xp7w-7w-0wk/s1600/photo.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://3.bp.blogspot.com/-hIxDsoziKTc/UHyHxACy1yI/AAAAAAAAAK4/Xp7w-7w-0wk/s1600/photo.jpg" height="320" width="240" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Another great buzz in the foyer. Not too unlike the sound of a Braun series 3.</td></tr>
</tbody></table>
<br /></div>
<div>
<h3>
Using nuget for fun and profit - Joel Hammond-Turner</h3>
</div>
<div>
Joel has found the solution to code reuse and its been right under our noses. It's NuGet! In this session <a href="https://github.com/JoelHT-Landmark/NuGet-PackageNPublish" target="_blank">Joel showed us how to set up our own NuGet server and his PublishNPackage</a> tooling. He's used this effectively to reorganise big code dumps of shared code and is now an integral part of his build process. We got a quick insight how this will be used with CI build too.</div>
<div>
<br /></div>
<div>
I just wanted to thank the organisers for today. It was amazing.</div>
Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-64572695511345776432012-07-25T22:12:00.000+00:002012-07-25T22:12:57.003+00:00Returning to Who is agileA few months ago I wrote a <a href="http://johnnosnose.blogspot.co.uk/2012/03/who-is-agile-review.html" target="_blank">review</a> of the <a href="https://leanpub.com/WhoIsAgile" target="_blank">Who is Agile</a> set of interviews compiled by Yves Hanoulle. Time has passed now as Yves has been back in touch and as the book has evolved I'm writing this follow up.<br />
<br />
I think that any community has its fair share of navel gazing and it seems that the agile community suffers especially from this. Too often the Agile manifesto's signatories are put up on pedestals and listened to without question. Too often are practicioners sat around telling each other "didn't we do well". When I first came to read "Who is agile" these were the biases that I was laden with and consequently I had some reservations of the underlying purpose of this book and the value that it would bring to those not in the circles of the contributers. I also think that this behaviour is why there are such strong opinions still over agile and I think that some of the criticism is valid.<br />
<br />
(It's probably worth reflecting on at this point that this cynicism may be saying more about me that it is about any community)<br />
<br />
So inspite of the review Yves has continued on with adding to the book and I've continued to read it.<br />
After grumpily dismissing the format I think I've now think I've worked out at least one way to read it. This book is not about names, nor agile. It's a book about people. If you forget the names and bio bits and just read the questions and answers you get a fantastic insight into how these people tick. Some of the best interviews are where the interviewees talk less about software development and more about the other stuff that defines them. I believe in that to be a good software developer you need to have experience in other 'stuff'. Some stories are very personal too and it's fascinating the influence that some of those incidents have on those people.<br />
<br />
I normally read the book on the kindle but that is only half the fun. As the book has become to big to email to the kindle (via gmail at least its > 20mb) I've found I read it less but when I do there's added value. Each interview is scattered with lots of hyperlinks, some go to just some strange places, others infomative distractions, or just plain definitons. You could get lost for hours just reading through some of the links and if you are stuck for ideas for books each interview will suggest a new one. This is really Who is agile's strengh. It's a cornucopia of information! (or a yak-shaving utopia).<br />
<br />
The other criticism I had originally was that the book had a narrow geographical focus. Yves has done well by getting a more diverse (geographically) set of people. Yes the book still is predominatly a euro-us set of interviews but there's more from futher a fields. This feels more like a truly diverse publication.<br />
<br />
I'm impressed with how the book has progressed. For its current minimum price ($9.49) there is so much in there. Don't be put off it you don't know (or like) agile. This is not an agile book, it's a book full of stories about software people.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-9429265247316338432012-07-23T22:27:00.001+00:002012-07-24T10:46:23.893+00:00The evils of auto properties & object initializers in c#I've been thinking a little bit about object orientation recently. It seems that OO was the poster child of the 1990s and has been the leading paradigm through the first decade of the new millenium. The thought behind this was that object reuse would solve all our problems but in reality they didn't. Even with languages gaining objects, C evolves to C++, and being built with objects from the ground up such as Java and C# people still seem to just not get it.<br />
<br />
Back in OO school I learnt that objects should be polymorphic, inheritable and encapsulate discrete bits of behaviour. In OO college I learnt that we should strive for low coupling between our classes and high cohesion. In OO university I learnt about the SOLID principles and that I should favour composition over inheritance. It's been a long journey and I'm still on it but all over I'm still seeing non OO code in .NET all over the place. Is OO too hard for people? Or is just a broken paradigm?<br />
<br />
Well my friends, OO is hard but I don't think the C# language designers have helped. The two worst features for Object Orientation in c# are auto properties and object initializer syntax. "What?" I hear you say, "Auto Properties? But they're so useful! (and cute). Object initializers they save so much time!"<br />
<br />
They are evil.<br />
<br />
More and more I'm beginning to see classes like this: <br />
<br />
<script src="https://gist.github.com/3169335.js"> </script>
<br />
and initialisation like this:<br />
<script src="https://gist.github.com/3169346.js?file=ap2.cs"></script>
<br />
<br />
People are abandoning the general principles of object orientation. We are exposing the internals of our objects with gay abandon. This is a dark route that inevitably leads to pain. Every time you use a vanilla auto property you are introducing an opportuntity for coupling, which reduces the modularity and resue of your code. Your classes becomes mutable so lose all the goodness that <a href="http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html" target="_blank">immutability</a> brings. By allowing 'Children' to be initialised in this way you break the Principle of Least Knowledge and couple your class even further. It's no wonder that we can't do OO if we take short cuts like this. Now of course there are reasons for using initializers, simple DTOs and anonymous classes spring to mind but don't be fooled by this syntactic sugar, it will rot your teeth!Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com4tag:blogger.com,1999:blog-10896391.post-60944824138225186492012-06-12T22:49:00.005+00:002012-06-13T08:10:51.229+00:00Source ControlI was just asked about source control by a friend that has only had experience in VSS. Thought I would share my rant:<br />
<br />
<blockquote class="tr_bq">
<div>
Git (and other DVCSs) are a revolution in source control. They
really are. Honest. I'll come back to why later but lets concentrate on
what you know, VSS.</div>
<div>
<br /></div>
<div>
VSS has a very bad
reputation nowadays. This is primarly because vss is known for
corrupting its repository
(<a href="http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html">http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html</a>)
but also because of its concurrency strategy, lock-unlock-modify</div>
<div>
(<a href="http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.lock-unlock">http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.lock-unlock</a>)
which has gone out of fashion. Most VCSs (e.g. svc, cvs) use
copy-modify-merge</div>
<div>
(<a href="http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge">http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge</a>)
because this allows more developers to work on the same bit of code at
the same time. This strategy is great but the risk is that you get
problems when you merge. Obviously you get conflicts when you are
merging in code into a different version of a file of the code you;ve
checked out but some people keep whole versions of the codebase unmerged
for extended periods of time. These can be versioned as well and are
know as branches. </div>
<div>
<br /></div>
<div>
The rational behind
branches is sensible. If you have major project N that is going to be
being built for 6 months then you will want to a) keep it in source
source control b) not have it messing up the code you are maintaining.
So a 'branch' of the code is taken and you have the benefits of source
control. the trouble comes when merging the branch back in
quite often the code is so divergent that you have to do a lengthy and
risk prone re-integration. (funny thing is that VSS has these
integration problems too). Lot's of people more clever than me have
struggled with this <a href="http://accurev.com/blog/2012/03/07/avoiding-merge-hell/" target="_blank">http://accurev.com/blog/2012/03/07/avoiding-merge-hell/</a> ,
<a href="http://martinfowler.com/bliki/SemanticConflict.htm">http://martinfowler.com/bliki/SemanticConflict.htm</a>l . Anyway the bottom
line is that merging is hard in many vcs's.</div>
<div>
<br /></div>
<div>
The
other issue with traditonal VCS's is that they make commits something
you do rarely. In a normal VCS you commit to a repositroy only when you are
finished. This goes against the meme 'commit early and often'
<a href="http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html">http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html</a>
. Wouldn't it be great to create check points when you've finished a
bit of code? Or if you just wanted to hide something somewhere? Also
what happens if you want to share you codebase with 2 or more servers?
Well in step DVCSs.</div>
<div>
<span class="yiv1447251146tab"><br /></span></div>
<div>
<span class="yiv1447251146tab">Distributed
Version Control Systems such as Git, Mercurial (also known as hg) make
the repository local. So you can have your own personal source control
system on your own machine. This means you have all the benfits of a VCS
locally. if your server goes down, you have the code. If you make a
mistake, you can rollback. It's awsome and it promotes commit early and
often. Git is even better because you can branch really easily and mor
important merge really easily so all this merge hell that occurs with
other systems is lessened (if you use it right). You can pull code in
form as many sources as possible and push up to them and every thing.
Git is so horrendously powerful that you can rewrite commit history,
cherry pick commits. This is also dangerous too. (with great power come
great responsibiltiy). It also means there's a crap load to learn. Also
for windows you have to use a linux shell and the tools
are best used on the command line. This also is a shock to windows
devs. Luckily github has brought out a windows client that makes the
experience more palatable. In short Git is much, much better than any
other VCS I have used despite its learning curve.</span></div>
<div>
<br /></div>
<div>
i've
not mentioned TFS. It's basically VSS next but with a CI server and an
issue tracker built in. Its fukcing awful. Read this article and
comments:<br />
<span class="yiv1447251146tab"></span></div>
<div>
<span class="yiv1447251146tab"><a href="http://www.itwriting.com/blog/4744-real-world-microsoft-team-foundation-server-not-very-good-says-thoughtworks.html">http://www.itwriting.com/blog/4744-real-world-microsoft-team-foundation-server-not-very-good-says-thoughtworks.html</a></span></div>
<div>
<br /></div>
<div>
I've used </div>
<div>
VSS</div>
<div>
SVN</div>
<div>
Star team</div>
<div>
TFS </div>
<div>
HG </div>
<div>
and Git in anger. SVN,HG and Git are the only ones I'd return too. SVN just looks like a dinosaur compared to the other 2.</div>
<div>
<br /></div>
<div>
Hope that helps.</div>
</blockquote>
<div>
<br /></div>
<br />Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-34099250230186943762012-04-11T21:02:00.001+00:002012-04-13T12:11:04.119+00:00Re: Over testingIt seems that one of the <a href="http://stackoverflow.com/q/153234/1116" target="_blank">questions</a> I asked on StackOverflow has gained some attention today, @dhh (of Ruby-on-Rails and 37Signals fame) mentioned it in a post on <a href="http://37signals.com/svn/posts/3159-testing-like-the-tsa" target="_blank">"over testing"</a>.<br />
<br />
He's railed before against <a href="http://www.rubyinside.com/dhh-offended-by-rspec-debate-4610.html" target="_blank">rspec</a> and now he's being vocal about automated developer testing in general.<br />
Whilst its great to question the status quo, I hope this doesn't signal a return to untested code.<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://upload.wikimedia.org/wikipedia/commons/2/2c/Flock_of_sheep.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="400" src="http://upload.wikimedia.org/wikipedia/commons/2/2c/Flock_of_sheep.jpg" width="261" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Is the flock now going to consider testing as harmful?</td></tr>
</tbody></table>
<br />
DHH's post, in my opinon is actually very good but it doesn't cover new ground. Its been observed for some time that :<br />
<ul>
<li>TDD is not about just 'catching bugs'. </li>
<li>100% Coverage is not pragmatic in 100% of cases.</li>
<li>Code coverage is a metric that is fundamentally useless. </li>
<li>Great swathes of tests are a maintenance headache.</li>
<li>Writing testable code is a constraint on your design. </li>
</ul>
Before I got into writing automated tests I used to write a pseudo code comment, then write the code, then remove the comment. Then unit testing came a long and I began to automate that psuedo-code. Of course things take longer this way. Not only do you have to solve the difficult problem but you also have solve the difficult "getting things under test" problem. But here's where the power lies: <b>By writing your intentions down you are forcing yourself to consider what you are doing</b>. Its an extra step. Yeah there will be some rock star, alcohol drinking brogrammer who can write that code a billion times better than you without tests but even ninjas make mistakes sometimes. So I prefer to set up a test up front.<br />
<br />
Now as time has progressed I find it more useful to write my expectations of what the stakeholders want. This means I think less about passing code and more about making features. TDD still has a place, a Behaviour Driven-style seems to fit better for me. Some of the BDD tooling I've used just was too much of an overhead in my situation, which is why our team dropped SpecFlow (a cucumber port) for MSpec (a cousin of RSpec). But<a href="http://blog.dextermixwith.co.uk/2011/11/a-non-framework-based-given-when-then-unit-testing-style/" target="_blank"> we don't need to use any of those tools</a>. It's entirely possible to do BDD with XUnit or anyother flavour of automated testing tools. It's just about OK to write tests after as long as you are clear what you are testing. (You wouldn't want to <a href="http://johnnosnose.blogspot.co.uk/2011/09/thoughts-on-retro-fitting-tests.html" target="_blank">test the wrong thing</a>.)<br />
<br />
What the rise of TDD has given us though is a focus on quality, a return to craftsmanship. We don't want a return to shops thinking its ok to just sling code out and for their customers (or QA) to deal with the aftermath. There is of course a balance. I'm glad that people are beginning to question the practice. Over the last few weeks I've heard Dan North, <a href="https://plus.google.com/104920553571646483561/posts/fmyZi1MxMgo" target="_blank">Michael Feathers</a> and now DHH push back but please don't stop testing.<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-24541205755548792492012-03-10T23:30:00.002+00:002012-03-10T23:30:57.596+00:00Who is agile : a review.I suprised myself last night in the reaction that I had to this <a href="http://leanpub.com/WhoIsAgile" target="_blank">book</a>. I wasn't sure what to expect from the book but I'd seen a couple of tweets about it. So I fired up leanpub, chose my price and downloaded.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/--VuE5tHWdr8/T1vjs9-cG3I/AAAAAAAAAJ4/_z84yLWrhic/s1600/conver.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="320" src="http://1.bp.blogspot.com/--VuE5tHWdr8/T1vjs9-cG3I/AAAAAAAAAJ4/_z84yLWrhic/s320/conver.png" width="235" /></a></div>
<br />
<br />
I loaded the pdf and flicked through the first few pages, skimming the contents, and reading a few further pages. The format is a standard set of questions, an extra question and a recommendation of who to interview. I flicked through the first interview with Lisa Crispin which was painless, relatively interesting, but the questions were uninspiring (I'm guessing a generic questionairre is difficult to 'jazz up').<br />
<br />
I then looked at the names down the list and thought about the format and felt little bit angry. Is this book an intropection of the circle that the authors know? What does it give to anyone else? What about all the people this book doesn't cover? Are they not agile?<br />
<br />
So I have some reserverations. I had kind of thought this book would be a guide of how to be agile. I was wrong. Fortunately, so far, it's not so bad.<br />
<br />
I probably know of, read, and respect 10ish of the 30 odd in the book. Some of the interviews I've read are fairly intesting but the power this book are the links that people mention. I've spent the last hour getting lost in the technical/agile and non technical books. The interviews are all light reading too. Something you can, by its nature pick up, read one and leave for a few weeks.<br />
<br />
What I was pleased about was the communites section at the back. There's a ton of interesting information and ideas about things you can do in your community some stuff I hope to bring.<br />
<br />
What I must remember is that this is a work in progress and it can be regenerated on demand. If agile is your thing or you are wondering if its more that just scrum & TDD then I'd certainly recommend you pick this up. If you are looking for another agile manual, there are better suited texts.<br />
<br />
Looking forward to the updates and following the links.<br />Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com5tag:blogger.com,1999:blog-10896391.post-83464496825329018492012-03-08T00:12:00.001+00:002012-03-08T00:12:30.309+00:00Sprint retrospective: INVEST in good stories.<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-ro3iV0AVCQA/T1dn1g3sFMI/AAAAAAAAAJw/9VTkCMjS8p0/s1600/bottleneck.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="240" src="http://2.bp.blogspot.com/-ro3iV0AVCQA/T1dn1g3sFMI/AAAAAAAAAJw/9VTkCMjS8p0/s320/bottleneck.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The column to the right of the 6 cards is 'done'</td></tr>
</tbody></table>
I've just come back from a sprint's worth of holiday and so unfortunately have not been able to be in work during the sprint. We set a fairly low and what I thought was an achievable target.<br />
<br />
However on my return I've see a lot of cards in the 'almost done' column. This was not the new beginning I had hoped for.<br />
<br />
In the retrospective, the team explain that the blue cards were all dependent on all the cards being done.<br />
<br />
The green cards were started by branching off the blue and therefore were dependent too. Nothing could go out. There's an acronym that can help here, <a href="http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/" target="_blank">INVEST</a>. Stories should be Independent, Negotatiable, Valueable, Estimatable and Testable. Because the project is a rewrite and we have made breaking changes the cards had to go out together. We have decided to consider more the impact of doing this in the future. <br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-90838120583357975332012-02-20T15:04:00.000+00:002012-02-20T15:13:12.973+00:00Process meltdown.After our process meltdown. We've decided to dust ourselves down and try again. What I think we've done is retrospect ourselves into a corner. We used retrospectives to remove the barriers to our productivity but by reducing some of the ceremony somehow we have removed all structure. This combined with a change in personnel and the disruption of the Christmas period has resulted in a development process that is best described as sluggish anarchy.<br />
<h2>
Rushing Shu, Ha, Ri</h2>
We've decided to re-adopt scrum again. Why? I feel we started to run before we could walk. There is a phrase that has been picked up by the agile community, <a href="http://c2.com/cgi/wiki?ShuHaRi">Shu, Ha, Ri</a>. This phrase borrowed from Akido shows different stages of learning.<br />
<blockquote>
In the phase of Shu, the person tries to abide by the rules. She tries to learn all the principles and informations by heart. But she can't abide by all the rules while she is doing the practice. Her body(including her brain) starts to remember them bit by bit through repetitious practices. When the time comes she can internalize and abide by all the rules -- when Shu is achieved, Shu phase is finished and she enters into Ha phase.<br />
In the phase of Ha, she tries to break the (old) rules. She tries to self-reflect on herself and her knowledge, and come up with anti-theses such as exceptions of the rules in the real world. But she can't break all the old rules while she is doing the practice. Her rules start to get more complete(or becomes more like "case-by-case") as the rules encompass exceptions bit by bit. When the time comes she can break all the rules and see the both sides of every rule (maybe substituting with a set of her own rules) -- when Ha is achieved, Ha phase is finished and she enters into Ri phase.
<br />
In the phase of Ri, she tries to leave the rules. She tries to get free from all the rules, and get into the state of no distinction, or into a new dimension. But she can't leave all the rules while she is doing the practice. Her body starts to forget them bit by bit through following natural laws and flows (or Tao). When the time comes she can leave all the rules -- when Ri is achieved, Ri phase is finished and she enters into a new dimension of Shu.
</blockquote>
We feel that we tried to enter the Ha stage before mastering the Shu.<br />
<h2>
Learning to fail habitually</h2>
The one thing I don't like about scrum is it is a framework for <a href="http://www.thehackerchickblog.com/2009/03/scrum-framework-for-finding-failure.html">exposing failure</a>. This can be used as a positive but after a number of failed sprints your team can become demotivated. We kept on over committing on story points per iteration and rather than reduce we tried to combat low velocity by removing impediments. This became habitual. We were learning to accept loss as a norm.<br />
<h2>
Process rebirth</h2>
So today we've started the sprint with a much smaller number of points. The idea behind this is that we can achieve the goal. Hopefully this will make us feel better about the process and motivated to continue.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-47446720067750293302012-02-16T22:22:00.000+00:002012-02-16T22:22:09.625+00:00acceptanceWe've been revisiting the <a href="http://pragprog.com/book/olag/agile-in-a-flash">Agile in a Flash</a> cards at the daily stand-up. As a team that purports to follow agile priniciples I don't mind saying that we've lost our way a little bit. By removing the percieved hurdles that were preventing from producing faster we seem to have gone too far. The process is lacking any structure at the minute but with new members of the team comes fresh energy. It's time to pull our socks up. What the cards do is provide us a discussion point to focus on and retrospect over where we've come from and where we want to get too. Admitting this is the first stage. Doing something about it is the second stage.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-25937483229568403862012-01-20T13:19:00.000+00:002012-01-20T13:19:23.372+00:00Metrolink: Highlights from the passenger's charterThe top web search result for "Metrolink Complaints" brings back
<a href="http://www.metrolink.co.uk/pdf/Passenger_Charter_Metrolink.pdf">Passenger Charter</a> last updated in 2008 it has some encouraging quotes.
All emphasis is my own.
<blockquote>
The vision behind the Metrolink system is to provide a safe, efficient
environmentally friendly and reliable tram system for Greater Manchester
that will integrate with other transport modes and fulfill the aspirations of
the Passenger Transport Authority.
</blockquote>
<blockquote>
Advance information on planned disruptions to service will be made
available as soon as practically possible in advance. Information will be
prominently displayed at all stops. We will always endeavour to minimise
passenger disruption to services.</blockquote>
<blockquote>
<b>We want all passengers to have a trouble free journey</b> and therefore ask
you to consider the needs of your fellow passengers at all times. </blockquote>
<blockquote>
We will continue to aim for improved standards of punctuality and
reliability. <b>We will publish our reliability and punctuality figures set against
agreed target levels at Metrolink stops every four weeks</b>. These figures will
be independently advised every year.</blockquote>
<blockquote>We will provide real time information about our services by means of
public address systems and information screens.</blockquote>
How many of screens actually work?
<blockquote>We recognise that passengers want to know what is happening when
things go wrong. Our staff on trams and on the Metrolink system will help
by providing as much information as they can to passengers. </blockquote>
<blockquote>For comments or complaints regarding general operation, maintenance
and cleanliness of the Metrolink system, passengers should contact
<b>Stagecoach</b>’s Customer Service team. For issues relating to policy, for
example fares and future Metrolink expansion, passengers should contact
GMPTE’s Customer Relations department.</blockquote>
Note Stagecoach do not run the service anymore.
<blockquote>If you have a complaint, we want to find out what went wrong and put it
right for the future.</blockquote>
<blockquote>Senior managers carefully monitor the number and type of comments we
receive. We will use this information to improve our service in the future. </blockquote>
This is my favourite
<blockquote><b>We do our best to give you the service you have the right to expect. Our
aim is to provide customer satisfaction by improving our services in
response to your comments.</b></blockquote>
<blockquote>
We will always do our best to satisfy all complaints. If you still wish to take the
matter further you can refer it to your local Passenger Focus Group, an
independent public body set up by the Government to protect the interests of
Britain's rail passengers. They are funded by the Department for Transport but
their independence is guaranteed by an act of Parliament. They use their
knowledge to influence decisions on behalf of rail passengers and work with the
rail industry, other passenger groups and government to secure journey
improvements.
The address for Passenger Focus in the area served by Metrolink is:
Passenger Focus
9th Floor
Store Street
Manchester
M1 2RP
Tel: 0870 336 6095
Fax: 0161 244 5981</blockquote>Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-62276490790109056612012-01-18T21:42:00.002+00:002012-01-19T11:01:55.663+00:00Manchester's Metrolink: An utter disgrace.<i style="font-family: Arial, sans-serif; font-size: small;">Regular reader. Sorry not a software topic just wanted to get some thoughts out.</i><br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://desmond.yfrog.com/Himg614/scaled.php?tn=0&server=614&filename=7o8pcx.jpg&xsize=640&ysize=640" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto; text-align: center;"><img border="0" height="320" src="http://desmond.yfrog.com/Himg614/scaled.php?tn=0&server=614&filename=7o8pcx.jpg&xsize=640&ysize=640" width="191" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">This morning's delayed tram</td></tr>
</tbody></table>
I love public transport. It's brilliant. Instead of crawling along in rush hour traffic, getting cramp in my foot as I leave the clutch at biting point I get to have a nice walk to the local public transport stop(healthy), stare vacantly into space as I wait for my carriage to arrive (meditative) and then I take a short journey where I read my book to somewhere vaguely near my destination (educational). Then I take a further walk and I'm there(even healthier). Or that's the idea.
It's not quite working out that way. You see I use Manchester's Metrolink.<br />
Metrolink is a light railway system that spans the city. When it was created it filled the need for better transport links from Bury and Altrincham to the city centre. I remember travelling on the Altrincham line for the first time. It was quick, clean and efficient. Sure there were some problems but my co-workers who used the system didn't seem to be affected too adversley. I don't know what's happened but things have got worse, much worse. I've been a commuter on the Altrincham line for 4 years and the service has degraded to such an extent that I feel that the people of Greater Manchester need answers from those who run the system.
So why do I feel angry?<br />
<b style="font-family: Arial, sans-serif; font-size: small;">Price hikes.</b><br />
On January 3rd prices across the system were <a href="http://www.bbc.co.uk/news/uk-england-manchester-11612792" target="_blank">increased on average by 6%</a> This price raise was described by the media as <a href="http://menmedia.co.uk/manchestereveningnews/news/transport/public_transport/s/1469101_price-of-metrolink-tram-tickets-to-rise-by-up-to-nine-per-cent-in-new-year" target="_blank">'Inflation busting' </a><br />
This irks me on two points. I thought the point of public transport was to provide cheap, quick, links across the city to stimulate the economy, and ease the burden on the roads. What instead has happened is that by raising prices potential commuters are driven away from using the Metrolink in favour of driving or just not bothering. This price hike has been introduced at the same time as Manchester city centre <a href="http://menmedia.co.uk/manchestereveningnews/news/s/1425210_motorists-hit-by-sunday-parking-charges-for-manchester-city-centre-bays-in-1m-funding-drive-by-council-" target="_blank">begins to charge cars to park on a Sunday.</a><br />
Its a 'double whammy' for Manchester residents and plays into the hands of places like the Trafford Centre which provides much better parking facilities and although there's not a Metrolink there, a reasonably efficient bus service.<br />
<b style="font-family: Arial, sans-serif; font-size: small;">Poor service.</b><br />
Since the price increase I have made 26 commuter time journeys. Of those journeys, 6 of them have had some form of disruption. That's 23% of my commuting journeys have had delays. In the last 2 days 100% of my journeys have been delayed. I'm writing this after spending 76 minutes on the tram (a normal jourey tkes 20 mins).<br />
<b style="font-family: Arial, sans-serif; font-size: small;">Tonight's Journey.</b><br />
This particular journey was so farcical it beggar's belief. I was travelling from Altrincham to Piccadilly to get to an event starting at 6.30. I buy a return ticket from Altrincham (more on this later)at 17.33. As soon as I set down the driver reports over the tannoy that there is a failed vehicle in the city centre and the line is suspended. Most people leave the tram, an angry few commutters are talking to the driver. I can just hear him and I'm sure he says that we shouldn't ring up to complain because that will just tie up the people trying to sort the problem out. I chance it and decide to wait - buses from Altrincham crawl up the A56 and to be fair Metrolink normally sort it within 20 mins and I've bought a ticket. After 10 mins or so the tram then starts moving. We are informed that the service will stop at Deansgate-Castlefield<br />
Altrincham is at the end of the line and just before the stop before (Navigation Road) the track becomes single file. There is signal where trams have to wait for the other to pass. Our tram pootles to there and then doesn't move for 10 mins. The driver then informs us that the he can't contact Network Rail to get the signal changed. We wait for what seems like another 10 minutes the driver then informs good news - the service will continue to Piccadilly. Unfortunately neither he or the control room can get the signal changed. Minutes pass and eventually we move. The driver apologies once again. <br />
We begin thundering up the line. Angry commuters squeeze on and off at Timperley, Sale, Dane Road, Stretford and Old Trafford but at least the thing is moving. We then stop just past Old Trafford. There's always a delay now between Old Trafford and Trafford Bar as the Chorlton line joins the Altrincham one. This delay seems to take longer than normal thought, it couldn't be ano... The driver comes on the tannoy. "Sorry blah ... blah... there's been a backup of all the trams trying to get through Cornbrook. We're just waiting for our turn". Fair enough. (I look at my watch its 6.30. I'm now late.) More minutes pass, I hear something over the driver's radio about telling customers of the Eccles & Chorlton lines that their tickets are valid on the buses. Phew! I'm on the Altrincham line. Driver comes back on, apparently the computer system is overloaded at Cornbrook so they can't let us move. I am now officially livid. My normal stop, Trafford Bar, is 200 yards away and Old Trafford is about 100 yards away and I am stuck on a packed tram, missing my evening event and unable to move. 18.49, 1 hour and 16 mins later I arrive at Trafford Bar. I should be in Piccadilly Gardens, 20 mins ago. Do I risk it? Can Metrolink get me 4 stops closer? I didn't want to find out.<br />
<b style="font-family: Arial, sans-serif; font-size: small; line-height: 18px;">Dealing with delays on the Altrincham line.</b><br />
I mainly travel between Trafford Bar and Altrincham. To catch up a common tactic of Metrolink is to terminate vehicles at Timperley so they can turn around. This means that commuters who want to go to Altrincham (read most of the people remaining) have to either wait or walk. Walking takes <a href="http://maps.google.co.uk/maps?saddr=Park+Rd%2FB5165&daddr=Stamford+New+Rd%2FA538&hl=en&sll=53.395946,-2.343349&sspn=0.018143,0.045447&geocode=FSDhLgMdpE_c_w%3BFb-iLgMd5Szc_w&vpsrc=0&dirflg=w&mra=ls&t=m&z=15" target="_blank">28 mins</a>. If most people are getting off at Altrincham why can't the service terminate at Navigation Road, 10 mins walk <a href="http://maps.google.co.uk/maps?saddr=Park+Rd%2FB5165&daddr=Stamford+New+Rd%2FA538&hl=en&sll=53.395946,-2.343349&sspn=0.018143,0.045447&geocode=FSDhLgMdpE_c_w%3BFb-iLgMd5Szc_w&vpsrc=0&dirflg=w&mra=ls&t=m&z=15" target="_blank">away</a>?<br />
There are 3 places on the line where trams get delayed.<br />
1) Between Altrincham & Navigation Road<br />
2) Between Old Trafford & Trafford Bar.<br />
3) Between Trafford Bar & Cornbrook <br />
Why can't trams wait in the stations for signals to change? At least then the commuters can make a decision of whether to stay on or off.
<b style="font-family: Arial, sans-serif; font-size: small; line-height: 18px;">Ticket inspectors over Safety Inspectors.</b><br />
In a bid to reduce the number of fare dodgers there have been an increase in the number of safety officers. At one point I've been checked 3 times on a journey. At no point have safety officers been there to prevent the over-crowding that occurs or been there to provide information when a delay happens,<br />
<b style="font-family: Arial, sans-serif; font-size: small; line-height: 18px;">Poor ticket flexibility</b><br />
Today I wanted to buy a ticket at Altrincham from Trafford Bar (where my season pass ends) to Piccadilly. So I have 2 options. I can either get off a Trafford Bar, buy a return from there and wait for the next tram or buy a full return from Altrincham. Today I spent £4.30 and gave up at Trafford Bar. <b>I actually paid twice for this journey.</b><br />
<b style="font-family: Arial, sans-serif; font-size: small; line-height: 18px;">What the hell is going on?</b><br />
It seems to be that this transport system is reeling from one cock-up to the next. I've had one person from my team at work leave due in part to the Metrolink commute. His train/tram season ticket was accepted by most inspectors but then he got slapped with a £50 fine (for his first offence!). Poor information on the train system caused this.<br />
<br />
There's probably more I could haul out of the memory banks if I wanted to, such as the cock up of the wiring at Altrincham where you had to pay someone to stand there until someone ordered some sleeving because it was too close to the footbridge. I think you get the idea though. <b>Metrolink is mismanaged and not fit for purpose</b>.<br />
I feel it's Metrolink's duty to explain its self and to sort it out!Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-51219525549323155292011-12-09T09:00:00.000+00:002011-12-09T09:00:09.968+00:00Metaphors in softwareMany Extreme Programming practices are now considered industry standard or at the very least 'worthy'.<br />
The poor cousin of these is perhaps the idea of System Metaphor. The intention behind XP's System Metaphor practice is to have a common <i>"story that everyone – customers, programmers, and managers - can tell about how the system works." </i>This story often is told in the language of the problem domain, there is no metaphor. (In XP terms this is known as a <i>naïve</i> metaphor)<br />
<br />
It was my guess that most systems are developed without a system metaphor (or a naïve one). So I thought I'd do an in depth study.<script src="http://twtpoll.com/js/ibadge.js" type="text/javascript">
</script><br />
<iframe frameborder="0" height="400" id="twpw_if" name="twpw_if" onload="TwtpwFm.registerFrame(this);" scrolling="no" src="http://twtpoll.com/badge/if/?twt=nrpjs4&r=1" width="100%">&lt;p&gt;&amp;amp;amp;amp;lt;p&amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;Your browser doesn't support iFrames :( Vote for this poll &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;a href="http://twtpoll.com/nrpjs4" title="here" target="_blank"&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;here&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/a&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;.&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;gt;&lt;/p&gt;</iframe><br />
Less than 20% of devs use the system metaphor. The evidence is damming!<br />
<br />
So do we even care about the system metaphor as a practice. If 80% of developers haven't used a system metaphor why would you even bother? Are developers missing a trick?<br />
<span style="font-size: large;">A world without metaphors. </span><br />
Metaphors are everywhere and in software land they are impossible to exist without. Why? Because the mechanics of what is actually happening is so far removed from what the typical user can communicate we need to abstract to understand anything. As a software dev, I don't want to have the overhead thinking about how the electrons fly around the computers, copper wires, through the air and I probably don't need to know too much how data gets from my HD into memory for example. Developers think at one level of abstraction, their clients work at another. The divide is there.. too often do stakeholders turn around and complain about the 'jargon' the developers use.<br />
<br />
So to allow the computer scientists to communicate with the devs they cooked up data structures. Think about the humble stack. <br />
<span style="font-size: large;">The stack datatype.</span><br />
<br />
A tangible stack is a set of objects placed on top of each other. To get to an item you need to remove the items above it. The last item you put on the stack is the first item you need to deal with. Now the CS boffins who were dreaming up datastructures came up with a collection of memory locations that were also to be last one in, first out. They could have called it anything (like particle physicists up, down, strange, charm, anyone?) and I bet in CS world there were some scientists that just didn't get the Stack straight away? So what's the best way of explaining a concept? Describe it in terms that explainee underderstands.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://www.flickr.com/photos/liopic/1871326475/" style="margin-left: 1em; margin-right: 1em;" title="Towers of Hanoi in the cooker by Julio Martinez, on Flickr"><img alt="Towers of Hanoi in the cooker" height="400" src="http://farm3.static.flickr.com/2016/1871326475_859e614eee.jpg" width="266" /></a></div><br />
<br />
A Stack data type is not vertically aligned. It has no physical dimensions. There are <b>holes </b>in the metaphor. As far as I know most "real" stacks don't pop either but the concept is good enough to convey the concept of how the data structure is supposed to function.<br />
<br />
The stack is just one example and, to be fair, a stack is a very simple concept. But look around the computer/software world and metaphors are just flippin' everywhere.<br />
<br />
In Design Patterns<br />
<ul><li>repository</li>
<li>bridge</li>
<li>adapter</li>
<li>factory</li>
<li>decorator</li>
<li>flyweight</li>
<li>mediator</li>
<li>command</li>
</ul>In Software Concepts<br />
<ul><li>error</li>
<li>bug</li>
<li>loop</li>
<li>concrete class</li>
<li>file</li>
<li>queue</li>
<li>peek</li>
<li>poke</li>
<li>pointer</li>
<li>engine</li>
<li>layer</li>
<li>core</li>
<li>service</li>
<li>bus</li>
</ul><br />
<br />
In the os paradigm<br />
<ul><li>file system</li>
<li>folders</li>
<li>recycle bin</li>
<li>window </li>
<li>lock</li>
<li>desktop</li>
<li>mail box</li>
<li>firewall</li>
</ul>and that's just the first few. Human's are naturally disposed to use metaphor and simile to explain concepts. The relatively dry topic of software engineering is an ideal breeding ground for metaphors. Most concepts are abstract and have no physical tangibility - what choice do we have? <br />
<br />
These aren't the sort of systems I build though. I build systems for businesses that help them streamline the business process. My systems have complexity. How can metaphors help us to construct these systems?<br />
<br />
<span class="Apple-style-span" style="font-size: large;">A Common Understanding</span><br />
Imagine you have two sets of people. The first set are a crack programming unit, the second are a group of domain experts. Both are knowledge specialists in their field. The project cannot fail. But when the two sets talk its like one group are from Mars and the other Venus.<br />
<br />
You have the option of getting the Martians to speak Venusian or the Venusian's could learn Martian ways. The problem you may come across here is that it takes a lot to learn Martian well. And boy those Venusians lead complicated lives. They are completely alien to those Martians.<br />
<br />
There's a third option: imagine if both Martians and Venusians have been observing Earthlings for a while then perhaps they could describe their problems using Earthling ideas and Earthling idioms.<br />
(Earthlings as we know are simple creatures with well defined funny-little habits).<br />
<br />
<span style="font-size: large;">But metaphors are alien to me?</span><br />
I suppose its quite disconcerting to not plump for the naive metaphor. It seems easy... but is it?<br />
Naive metaphors are a one way street. The dev team may potentially know nothing about the domain it is going to work with. The stakeholders hold all the cards.<br />
<br />
In the short term it is probably easier for the delivery team to learn about the problem domain.<br />
What can happen though is that there may be an incomplete transferral of knowledge to the delivery team. I suppose that this unlikely to be too much of a problem in an iterative project. Agile accepts that not everything will be right first time but that doesn't mean we should aim to close the iteration loops.<br />
<br />
By introducing a metaphor the knowledge holders have to 'think' about how their domain is relates<br />
to the metaphor. Processes that are 'second nature' need to be be deliberately revisited and described not only in terms of the business stakeholders but in a shared and a discovered paradigm.<br />
<br />
This joint learning I feel has some value. It seems strange that this practice is not more popular.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-10112745443981532022011-09-15T19:59:00.000+00:002011-09-15T19:59:14.816+00:00Thoughts on retro fitting tests.<div>Had an interesting talk with a colleague of mine some time back on the topic of retrofitting tests to a system. I'm not a fan of retro fitting for the sake of it. The, now hopefully well documented, problem with TDD is that the 'test' bit is a side effect. Its practically a distraction to the design aspect of TDD. So when I get told to write 'unit' tests against an code base, I accept they are not going to be the same sort of unit tests as those that I would write when I'm doing test first.<br />
<br />
So why do I have an issue?<br />
When we retro fit unit tests, <b>the best we can do is make observations of the current state of the system</b>. This system may be subtly wrong, how can we know if we have no specification to verify against? At the unit level such detail may not be understood by the business. The scenario that the code was written under is most likely forgotten or more likely misunderstood. So when we write tests we merely <b>observe and report</b>, we cannot say that we understand.<br />
<br />
I came across this issue, yesterday. My pair and I were refactoring some code and saw a redundant switch statement. looking at the system hollistically, it was obvious that the code didn't belong so we whipped it out, ran the tests and got red.<br />
<br />
The production code was something like this:<br />
<br />
<br />
public string GetContent(int fooId)<br />
{<br />
var content = string.Empty;<br />
<br />
switch (fooId)<br />
{<br />
case 4:<br />
return _contentModule.GetContent();<br />
}<br />
<br />
return content;<br />
}<br />
<br />
We knew that fooId would only ever be 4, (cough magic number) and so could simplify this method down but when we ran the test, we failed on:<br />
<br />
public void Should_return_stringEmpty_when_fooId_not_equal_to_4()<br />
<br />
When I looked at the log in source control it revealed that the tests had been committed 3 months after production code had. I'm guessing then that the test author had merely looked at the code and applied a test based on what the code actually does rather than the intent.<br />
<br />
This retro fitting of tests can therefore be dangerous. If we trust the tests (and we should) then retro fitting can be misleading and it is against the TDD ethos. Remember kids you should value specifying over verifying. <br />
<br />
<br />
</div>Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-58601207564705268302011-06-18T23:42:00.001+00:002011-06-18T23:43:49.792+00:00Jack and Jill rewrite a system and then go on a digA software system is like a bucket of water.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://4.bp.blogspot.com/-O9S039dcyH0/Tf014RIMn9I/AAAAAAAAAHY/aGFId-Z6AAs/s1600/leaky.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="214" src="http://4.bp.blogspot.com/-O9S039dcyH0/Tf014RIMn9I/AAAAAAAAAHY/aGFId-Z6AAs/s320/leaky.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Photo by <a href="http://www.flickr.com/photos/tobiasschlitt/">Tobias Schlitt</a></td></tr>
</tbody></table><br />
But other than just the code and the persistence of data there's knowledge too. Knowledge about the system that is sometimes stored in documents, sometimes stored in tests but always stored with people.<br />
<br />
I've just been watching Scott Bellware's "Beyond <a href="http://www.ndc2011.no/agenda.aspx">Agile</a>" talk and he talks about software development of simply being knowledge transfer. A product sponsor transfers the knowledge to an analyst, who transfers to the business analyst, who transfers to the develop to tester into a product.<br />
<br />
When we rewrite systems we will leak this knowledge. Exactly if you tried to pour a full bucket of water into another bucket or water. Chances are you'll spill a bit. Chances are the documentation is not comprehensive. Chances are the tests don't convey the meaning of the application well enough. Chances are the developers have forgotten what they were doing when they wrote that feature. Chances are the product sponsor has forgotten exactly why they wanted it 'that' way.<br />
<br />
When system stakeholders leave the project the bucket springs a leak. You have lost some of that knowledge. Even with comprehensive documentation, tests and a full handover. And your bucket is probably not a bucket any more. What once was a bucket is now probably a kettle that does credit card payments... and its rusty but only on a Thursday.<br />
<br />
So how do I summarise this leaky abstraction? (go on groan)<br />
<br />
A software system is is more than just code. It is the users, the stakeholders, the delivery team and the state of the system. When rewriting the system it is going to be impossible to relive the journey of knowledge accumulation that the team went through to get to the system that you are rewriting. Even though there will be a set of artefacts you will have discovered to reconstruct the system this will not be the full picture. That's ok because you only need to do what your stakeholder's need now. Reconstructing 100% of the old system when no one knows what 100% is wasteful (and impossible)<br />
<br />
Rewriting software is like an archaeological dig.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/--FG5jRFST_k/Tf02-kqr2pI/AAAAAAAAAHc/p_m_BE377Zc/s1600/dig.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="240" src="http://3.bp.blogspot.com/--FG5jRFST_k/Tf02-kqr2pI/AAAAAAAAAHc/p_m_BE377Zc/s320/dig.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Photo by <a href="http://www.flickr.com/photos/bengarney/">Ben Garney</a></td></tr>
</tbody></table><br />
Except rather than rebuilding the Roman fort exactly we extract what we want from it and make it better.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-72231647753270125102011-06-13T13:53:00.001+00:002011-06-13T14:13:28.312+00:00DDDSW 3 - RE: the ReWrite session.I went to <a href="http://www.dddsouthwest.com/">DDDSW</a> on Saturday( a conference based around Microsoft technologies) specifically to see one session.<br />
<span style="font-size: large;"><br />
"Rewriting software is the single worst mistake you can make - apparently" by <a href="http://twitter.com/fatherfil">Phil Collins</a>.</span><br />
<br />
This subject is dear to my mind as I've been involved in many rewrite projects over the years with varying degrees of success. Its also a big part of my studies at the minute.<br />
<br />
Phil is a confident speaker and this session is an experience report rather than a "How to" session. Some of the choices that Phil has made I disagree with. I want to share the reasons why I disagree, not to have a pop at Phil but just to get clear in my mind why I do.<span style="font-size: large;"><br />
</span><br />
<span style="font-size: large;"> Language choice</span><br />
Phil was moving from an old tightly coupled legacy system and he had a free choice of languages. He quite rightly had an R & D session on a few languages. However the basis of the choice he made given in the talk was problems with case insensitivity. There are many factors for choosing a language, tooling support & flexibility are two that spring to mind but the issues that you have in the first few weeks you will soon forget and so case insensitivity is a minor distraction in my opinion. Choose a language and platform that is right for the application not just the rewrite project.<br />
<br />
<span style="font-size: large;">Screen by screen rewrite.</span><br />
Why? Sure you get all the features but this is an excellent time to find out exactly what you do use and more importantly what you don't. I know this from first had experience. I joined a rewrite project late that had done exactly this. There were dozens and I mean dozens of text boxes and fields in the application that were not used any more. Whole screens were devoted to the parts of the business that just didn't exist any more.<br />
<br />
Take the time to talk with your users about each screen. Try and come up with the story behind each feature. If your users don't need it. Don't rewrite it. This saves you time and gives you opportunity to remove cruft from your application.<br />
<br />
To be fair Phil did share a story where he added more features based on user interaction. I'm assuming that he may not have blindly rewritten all features.<br />
<br />
What Phil has got right:<span style="font-size: large;"><br />
</span><br />
<span style="font-size: large;">Continuous integration.</span> <br />
Phil lauds this and has a very funky set of build radiators. (BVC of the build status) and I agree. CI is instant feedback and build radiators are key to that feedback.<br />
<br />
<span style="font-size: large;">Slowly, carefully.</span><br />
Phil tells his devs to go slowly. Any project should not be done a break neck speed. Otherwise you are under pressure to cut corners. If you are just in a race to rewrite a function you will make mistakes. A rewrite is an opportunity to cut tech debt. Don't make the mistake of adding more.<br />
<br />
<span style="font-size: large;">More Whiteboards</span><br />
... I love just scribbling down stuff on white boards too. It is simply a great way to share ideas and concepts.<br />
<br />
<span style="font-size: large;">What I would do - ascertain the vision</span><br />
<span style="font-size: large;"><span style="font-size: small;">Assuming</span> <span style="font-size: small;">that the rewrite has to be done. I would try and extract the vision for the project. Why is it that we have to do this rewrite? What are we trying to get out of the the rewrite? It may be to improve usability or performance. It may be for legal reasons. It may be the the cost of change is high in the legacy application or that the technology is just not supported. </span></span><br />
<span style="font-size: large;"><span style="font-size: small;"><br />
</span></span><br />
<span style="font-size: large;"><span style="font-size: small;"><span style="font-size: large;">Observe system usage</span></span></span><br />
<span style="font-size: large;"><span style="font-size: small;">Given we now have a vision, a set of woolly statements that we are heading towards we can now look at the current application and its features. Look at each of the features and see if they still align with how the users are using them. A good idea here is to sit with the users and observe their daily activity. Its an eye opener to see how your application is actually being used and its often not as designed. Of course you will not all of the usage in just one session but you will certainly get the core. </span></span><br />
<br />
<span style="font-size: large;"><span style="font-size: small;"><span style="font-size: large;">Speak with your users</span> </span></span><br />
<span style="font-size: large;"><span style="font-size: small;">Next step is to interview your users find out what they think their processes are. At this point you should pick up things they do that you didn't pick up on the initial sweep. This is a great opportunity to find clunky procedure where you can improve upon. Many times I've done this and found hidden manual process too.</span></span><br />
<span style="font-size: large;"><span style="font-size: small;"><br />
</span></span><br />
<span style="font-size: large;"><span style="font-size: small;"><span style="font-size: large;">Collaborate to write automated specifications</span></span></span><br />
<span style="font-size: large;"><span style="font-size: small;">Now that you have a vision, an idea of how the users are using the system and the processes they are trying to follow you can begin to look at the features the system needs to achieve the processes. These features can be broken down into user stories and then you can provide examples to specify the features. A tool like Cucumber (or SpecFlow) can work well in situations like this. Now that your specs are automated you can get that cosy feedback loop when you check with your CI system.</span></span><br />
<span style="font-size: large;"><span style="font-size: small;"> </span></span><br />
<br />
<span style="font-size: large;"><span style="font-size: small;"><span style="font-size: large;">Iterate</span></span></span><br />
<span style="font-size: large;"><span style="font-size: small;">Split your work up into chunks. Stop then reflect. Are we missing something? If so add it. Show your work to your users regularly. Rollout to them as soon as possible and as much as possible.</span></span><br />
<br />
<span style="font-size: large;"><span style="font-size: small;"><span style="font-size: large;">Summary</span></span></span><br />
<span style="font-size: large;"><span style="font-size: small;"><span style="font-size: large;"><span style="font-size: small;">Phil's got some good ideas but his focus is different from mine</span>. <span style="font-size: small;">Check out his blog</span></span> <a href="http://soyouthinkyouneedtorewrite.com/">http://soyouthinkyouneedtorewrite.com/</a> for some views on rewrites and if he does his talk near you go see it. But also don't rewrite feature for feature. Take the opportunity to prune dead features and improve existing ones.</span></span><br />
<span style="font-size: large;"><span style="font-size: small;"><br />
</span></span>Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-59732661505886423702011-06-05T01:38:00.000+00:002011-06-05T01:38:13.537+00:00Actually all we care about.Mary Poppendeick is a legend. She's got a fantastic paper about team <a href="http://www.poppendieck.com/pdfs/Compensation.pdf">rewarding</a>, But I've just been reading her paper about lean thinking. "Wow John. Lean's so old now its in a nursing home." but hey I've just Mary's principles of lean thinking. Its nothing new if you aren't on the agile slug trail but i kinda missed it. <br />
<br />
So for everyone else;<br />
<br />
here's what you are doing.<br />
<br />
<span class="Apple-style-span" style="font-size: x-large;">YOU ARE WASTING YOUR TIME</span><br />
Mary and some guy from japan have noticed that:<br />
<br />
<br />
<div style="font: 12.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;"><b>The Seven Wastes of Software Development</b></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Overproduction = Extra Features</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Inventory = Requirements</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Extra Processing Steps = Extra Steps</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Motion = Finding Information</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Defects = Defects Not Caught by Tests</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Waiting = Waiting, Including Customers</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Transportation = Handoffs</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;"><br />
</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;">Can you see this in your organisation?</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: x-small;"><br />
</span></div><div style="font: 10.0px Arial; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-style-span" style="font-size: small;"><b><i><br />
</i></b></span></div>Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-65557630674887672752011-06-05T00:56:00.000+00:002011-06-05T00:56:48.885+00:00Nobody cares about agile but youA poem :<br />
I remember when I was concerned when agile was something that 'hippies did' (& me). I remember when people thought that agile meant no docs. I vaguely remember the acceptance. i don't remember the corporate adoption. I remember the scrum certification. I remember that now that the literati accept agile as a given. I remember moving jobs to an agile organisation. I remember how nothing had changed. I remember how this was not agile. I remember how we can do better. I remember the alt.net implosion. I remember the bright days of dev div. I remember the betrayal of people's hard work. I remember getting my team to think about objects. I remember to get them to think about tests. I remember just writing code. I remember loving results. I remember loving the problem I remember loving quality. I remember evolving design. I remember just wanting to make things better. I remember the stand ups, I remember the cynicism. I remember the hope. I remember the break through. I try. We improve. we improve.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-41195435519708598332011-06-04T23:25:00.000+00:002011-06-04T23:25:09.857+00:00ORMsThere has been a backlash against ORMs. I missed it. While you were all messing around with Nhibernate. I avoided it. Why? because I can always write database queries much easier in SQL.<br />
<br />
Always.<br />
<br />
My mappings were much better when I mapped in with NH. I've always worked in smaller teams and much of the code has been written procedurally.<br />
<br />
There I said it.<br />
<br />
But this is why I like ORMs... because over several years into .net people are still writing procedural code. For the first time people were forced to think about domain objects.<br />
<br />
and now we have EF. Ef is now getting people to think code first. (Wow welcome to the 1980s)<br />
<br />
and now we have stuff simple.data.<br />
<br />
ORMs were supposed to remove the impedance mistmatch between tables and code. This has only been solvee if your forward generate.<br />
<br />
For those of us with legacy systems all this backwards mapping is too much of a ball ache.<br />
minimilist web frameworks don;t help and this is why I'm writing crap like SQl.data.<br />
We don't need to worry what to call our call because its the name of the entity. we don't need to worry about joins because its the best SQL we can write.<br />
<br />
Lets not worry about the mismatch because we can do what the devs did in the 80s. We write the best DSL to query data evar. S Q L.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-72812055180414453692011-05-24T21:32:00.000+00:002011-05-24T21:32:38.381+00:00Research in re-writing systems.I'm doing some research into re-writing systems with automated tests and I'm trying to get a feel for what the status quo is in this area.<br />
<br />
If you've got a spare couple of minutes to fill in this short survey. I'd very much appreciate it.<br />
<br />
<a href="http://edu.surveygizmo.com/s3/549590/Re-writing-systems-with-TDD-and-BDD">My survey</a><br />
<br />
If you don't want to do it.... well baby jesus will kill a kitten or something.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-4466282671484755132011-04-23T23:06:00.000+00:002011-04-23T23:06:43.717+00:00Test coverage or specificationWhilst writing up some notes I keep on changing between tests that cover something (as in test coverage) and tests that specify behaviour. It strikes me that these two concepts are orthogonal to one another. The former is an after thought, something that aids regression, the latter a pre-requisite to writing the code.<br />
<br />
The funny thing is that I hear about test coverage but we never talk about specification coverage.Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0tag:blogger.com,1999:blog-10896391.post-31569807905329998152011-04-23T13:07:00.001+00:002011-04-23T13:12:54.564+00:00TDD for abstract classesI don't seem to use abstract classes much anymore. The tendency is for me to prefer interfaces over abstract classes as I've been inculcated with mantra 'composition over inheritance'. Where common behaviour is observed though it just feels natural to shove that behaviour in , I dunno, something like a superclass.<br />
I like the template pattern too. So I do use abstract classes occasionally.<br />
<br />
Concerning testing I have tended to duplicate testing this behaviour in the past. This is something that has not settled well. Duplication in testing may be slightly less repugnant than duplication in production code but there must be a valid reason.<br />
<br />
How should we tackle testing abstract methods then?<br />
Here are a couple of strategies.<br />
<br />
Firstly here is my class<br />
<script src="https://gist.github.com/938572.js?file=MyAbstractClass.cs">
</script><br />
<span class="Apple-style-span" style="font-size: large;">An abstract test class</span><br />
We can put the tests for the behaviour into an abstract test class using a protected but uninitialised instance member. In our concrete sub class test class we inherit from the abstract test class and instantiate the sub class variable When we run the tests the superclass tests run with the subclasses.<br />
If the subclass has more methods that need to be tested then a clumsy casting of the concrete type over the instance variable has to performed each time we test. Alternatively a separate member of the subclass needs to be setup as well the abstract one.<br />
<script src="https://gist.github.com/938579.js?file=abstractTestClass.cs">
</script><br />
<span class="Apple-style-span" style="font-size: large;">An mock of the abstract class</span><br />
Alternatively we can use a mocking framework to mock the abstract class and run tests on that.<br />
<script src="https://gist.github.com/938584.js?file=AbstractWithAmock.cs">
</script><br />
<span class="Apple-style-span" style="font-size: large;">A fake concrete class</span><br />
If the feeling of mocking an abstract class doesn't sit well an slight variation would be to create a fake concrete instance and perform the tests on that.<br />
<script src="https://gist.github.com/938588.js?file=Fake.cs">
</script><br />
If I was using Mspec today I could has used its behaviours functionality which may have been more simple but I wanted to see from a TDD point of view what options I had.<br />
<br />
Do you use any other strategies for testing abstract classes?<br />
<br />
<a href="https://github.com/johnnonolan/Testing-an-Abstract-Class-Strategies">All the code if you want it</a>Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com2tag:blogger.com,1999:blog-10896391.post-40317653460996523662011-04-22T05:27:00.000+00:002011-04-22T05:27:15.243+00:00TDD StrategiesJust scribbling some notes thought this looked bloggable: <br />
<br />
<br />
Test Driven-development can be approached using at least two strategies, a mock based approach or a state based approach (Martin Fowler calls this a classicist approach <a href="http://martinfowler.com/articles/mocksArentStubs.html">http://martinfowler.com/articles/mocksArentStubs.html</a>). When presented with the initial idea, TDD seems simple; write the test to verify the behaviour code you are about to write. A common example of this is a calculator.<br />
<br />
Say we have a calculator class that has the following method:<br />
<br />
public void int Add(int integer1, int integer2)<br />
<br />
We may write a test to verify this works first;<br />
<br />
public void Should_Sum_inputs_together()<br />
{<br />
var result = new Calculator().Add(1,4);<br />
Assert.AreEqual(5,result);<br />
}<br />
<br />
This is probably the defacto example of a state based testing approach. An action is performed on a class, and then its state is interrogated or a return value is verified. In many introductions to TDD you will find trivial examples such as this one. When test-driving code ‘in the wild’ you soon find that certain things become more complex very quickly.<br />
Mock based TDD<br />
Continuing on with the calculator example we can see where state based testing alone may not be enough.<br />
<br />
Say we move a little closer to the GUI and have a ButtonInterface class that implements the interface,<br />
<br />
IButtonInterface<br />
{<br />
Button Zero;<br />
Button One;<br />
…<br />
Button Nine;<br />
Button Add;<br />
Button Equals;<br />
void PressButton(Button button);<br />
}<br />
<br />
Our test may be :<br />
public void Should_Sum_inputs_together()<br />
{<br />
//mock a calculator -- I’m using pseudo code based on Moq<br />
var mock = new Mock<icalculator>();<br />
ICalculator calc = mock.Object;<br />
IButtonInterface calcUI = new ButtonInterface(calc);<br />
calcUI.PressButton(this.One);<br />
calcUI.PressButton(this.Add);<br />
calcUI.PressButton(this.Four);<br />
calcUI.PressButton(this.Equals);<br />
mock.Verify(c => c.Add(1,4)); <br />
}<br />
<br />
When testing the button interface we do not need to know how our class that does the addition manages the task. It is not the responsibility of the button interface to do so. However it is the responsibility to take the button inputs and send the appropriate messages to the calculator.<br />
This is where mock based testing comes in. If the ICalculator interface hasn’t been written yet or perhaps there is a cost in setting up an ICalculator, for example it may be dependant on a filesystem or a database. In these cases tests may run slowly due to getting the dependancy into the correct state and then resetting it afterwards. In these examples and the more striking fact the the ButtonInterface doesn’t care all we need to verify is that the correct message has been sent to the correct interface.</icalculator>Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com1tag:blogger.com,1999:blog-10896391.post-2822260135574899352011-03-19T10:25:00.001+00:002011-03-19T11:36:59.754+00:00Getting Better Steadily<a href="http://agileotter.blogspot.com/">Tim Ottinger</a>, asked me to write a few words for him about the <a href="http://pragprog.com/titles/olag/agile-in-a-flash">Agile in a Flash</a> cards he co-authored. I bought these recently to help us reboot the team into something more agile. The cards are great, concise pieces of information that we reflect on each morning. They started off on my desk but it was fantastic to see them missing from my desk and being talked about by the other developers. This hasn't happened with books or blog posts because the information in a book is usually buried 100s of pages in and 19" monitors are well, just not mobile enough. The cards invite being passed around and collaborated with. It's wonderful to see that happening.<br />
<br />
Anyway if you want to, <a href="http://agileinaflash.blogspot.com/2011/03/getting-better-guest-blog-post.html">read my story</a> on the Agile in a Flash <a href="http://agileinaflash.blogspot.com/">blog</a><br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://imagery.pragprog.com/products/217/olag.jpg?1298589962" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://imagery.pragprog.com/products/217/olag.jpg?1298589962" width="228" /></a></div>Anonymoushttp://www.blogger.com/profile/15620075254402056526noreply@blogger.com0