tag:blogger.com,1999:blog-2595368033671683852023-11-16T06:34:10.296-08:00My software interestsSaleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-259536803367168385.post-42817689564812751632016-04-13T14:53:00.002-07:002016-04-13T14:54:03.809-07:00Pattern seeking or pattern making<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.8px;">
<div>
<div>
<i>[This piece was part of an e-mail I sent to a colleague after interviewing a candidate.]</i></div>
<div>
<br /></div>
<div>
I used to think of us humans as pattern <i>seekers</i>. Now I'm inclined to think of us as pattern <i>makers<b>. </b></i>We imprint patterns upon unconnected events. We <i>need</i> to. Finding method, structure and causation in everything is not only intellectually satisfying; it's an evolutionary survival skill. If <i>most</i> sabertooths lurk in tall savanna grass, then it's advantageous to associate the pattern of swaying blades of grass with danger. That's why abstract art works, and traffic lights ... and our intuitions about people. <i>Most of the time</i>.<br />
<br /></div>
Smiling people are <i>mostly</i> friendly. Frowning people are <i>mostly</i> unfriendly. Talkative people who monopolize conversations and say things like "those PhD candidates knew more than they think" are <i>mostly</i> dominant, polarizing types.</div>
<br />
However, these pattern-forming traits of ours aren't fail-proof. We find that smiling politicians act like barbarians. We find that genuine-looking works of art are fakes. And we may find that garrulous, opinionated people are in fact quite genuine, warm, insecure types under the bluster.</div>
<span style="background-color: white; color: #222222; font-family: "arial" , sans-serif; font-size: 12.8px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , sans-serif; font-size: 12.8px;">As I grow old(er), I trust my intuitions less and less, and the world is an ever-more brilliant place because of it!</span><br />
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , sans-serif; font-size: 12.8px;"><br /></span></div>
<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 12.8px;">
<div>
</div>
</div>
Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-86005513563737290532015-01-06T05:24:00.001-08:002015-01-06T05:24:33.103-08:00Retrospective Prime Directive in UrduI haven't found an Urdu translation of the Retrospective Prime Directive. I'm furnishing one here in the hope someone finds it useful.<br />
<br />
<div class="p1">
<b>Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.</b></div>
<div class="p1">
<b><br /></b></div>
<br />
<div class="p1">
<b>قطع نظر ان تمام باتوں سے جو ہم ابھی دریافت کریں، ہم یہ نہ صرف سمجھتے ہیں بلکہ یقین محکم سے جانتے ہیں کہ ہم میں سے ہر شخص نے اس وقت پر دستیاب معلومات، اپنی مہارات اور صلاحیات، اور موجودہ وسائل کے مطابق بہترین کام انجام دیا، جو اُس صورت حال میں کیا جا سکتا تھا۔</b></div>
Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-84128678445880459882014-08-02T10:35:00.000-07:002017-01-31T19:44:39.553-08:00Privilege of different kindsPrivilege can come packaged in multiple forms. Here are a few I've experienced.<br />
<br />
As a male software developer, I am given privilege that is undeserved. When I speak at conferences, or in front of a client, or while facilitating a workshop; I cannot help but be aware that if I were a woman, it wouldn't be as easy. For one, I would probably not have as many opportunities to speak in the first place. For another, I'd probably be taken less seriously when I did speak.<br />
<br />
Being a man in my industry gives me undeserved privilege. And I despise that.<br />
<br />
As a dark-skinned man with a <a href="https://www.facebook.com/photo.php?fbid=10156069953115176" target="_blank">security-alert-causing-name</a> who was born in what, according to one news outlet, is the <a href="http://www.forbes.com/sites/dougbandow/2013/05/20/the-islamic-republic-of-pakistan-the-worlds-most-dangerous-nation-holds-an-election/">most dangerous country in the world</a>, I lose privilege when I walk into an airport. It is depressing to know that in the US, even the <a href="http://fas.org/sgp/crs/misc/RL31130.pdf">law isn't necessarily on the side of justice and equality</a>. It requires a much higher burden of proof to show discrimination in the <i>civil</i>, as opposed to <i>statutory</i> context. I have to accept the reality that I am subject to a different set of laws and regulations when I'm in an airport.<br />
<br />
Laws that suspect me because of my ethnicity, name and place-of-birth take away my privilege. And I despise that.<br />
<br />
Then there's the privilege of working with people who I call my friends. The privilege of learning from them, being able to share with them what I've learned before. The privilege of their company, the insight into their thoughts and feelings, the human connection that is the underpinning of all creativity and an indispensable prerequisite to crafting beautiful software.<br />
<br />
Working with creative, passionate, motivated, empathic friends is a privilege that I acknowledge consciously and for which I am very grateful. And I love that.<br />
<br />Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-35245398216937982542012-10-31T07:55:00.001-07:002012-10-31T07:55:43.203-07:00Beware of the translated Arabic Agile Manifesto<div style="color: #575757; font-family: arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; margin: 0pt; padding: 0pt;">
(And not just because the world gets its hackles raised when they see "Arab" and "Manifesto" in close proximity.)</div>
<div style="color: #575757; font-family: arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; margin: 0pt; padding: 0pt;">
<br /></div>
<div style="color: #575757; font-family: arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; margin: 0pt; padding: 0pt;">
The Agile Manifesto has been translated into many languages, including a few that are written from right to left like <a data-mce-href="http://agilemanifesto.org/iso/ar/" href="http://agilemanifesto.org/iso/ar/" style="color: #2989c5; text-decoration: none;">Arabic</a> and <a data-mce-href="http://agilemanifesto.org/iso/ur/" href="http://agilemanifesto.org/iso/ur/" style="color: #2989c5; text-decoration: none;">Urdu</a>. If you translate one of these using Google Translate [1], you'll be misled. Because Google will translate the last sentence starting with<span data-mce-style="font-size: 10pt;" style="font-size: 10pt;"> و یعنی</span> (AR) or <span data-mce-style="color: #000000; font-family: Times; font-size: 10pt; text-align: -webkit-center;" style="color: black; font-family: Times; font-size: 10pt; text-align: -webkit-center;">یہ اسلئے</span> (UR) literally. Which comes out to "... we give greater value to items on the right side". This is a literal translation, but it's false. Because in the original Arabic, the "items on the right side" are <span data-mce-style="color: #000000; font-family: Times; font-size: 10pt; text-align: -webkit-center;" style="color: black; font-family: Times; font-size: 10pt; text-align: -webkit-center;">الأفراد وتعاملهم فيما بينهم</span> (individuals and their mutual interactions), <span data-mce-style="color: #000000; font-family: Times; font-size: 10pt; text-align: -webkit-center;" style="color: black; font-family: Times; font-size: 10pt; text-align: -webkit-center;">البرمجيات الصالحة للاستعمال</span> (correctly working software), etc. You know, the things we <em>all</em> value highly.</div>
<div style="color: #575757; font-family: arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; margin: 0pt; padding: 0pt;">
<br /></div>
<div style="color: #575757; font-family: arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; margin: 0pt; padding: 0pt;">
Context is everything. If you don't pay attention, your left hand won't know what the right hand values more.</div>
<div style="color: #575757; font-family: arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; margin: 0pt; padding: 0pt;">
<br /></div>
<div style="color: #575757; font-family: arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; margin: 0pt; padding: 0pt;">
[1] Very easy to do if you view the page using Google Chrome.</div>
<br />Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-56894953023692752092012-02-25T05:25:00.004-08:002012-02-25T14:11:23.239-08:00Organizational DysmorphiaIn my consulting work, I've all too often observed organizations that have chosen to structure themselves in a way that is at odds with their stated goals and objectives. In extreme cases, the structure of such an organization actively subverts its raison d'être. I term such self-defeating structures as <span style="font-weight: bold;">Organizational Dysmorphia</span>.<br /><br />A recurring example is when the development and quality-assurance teams are isolated from each other and evaluated on mutually inconsistent criteria. The development team is measured on the amount of functionality (feature-points, story-points, etc.) that they deliver to the QA team. The latter, in turn, are measured on the number of defects they can find in the software they receive from the development team. This arrangement actively dissolves any collective focus on quality and instead promotes a highly localized -- almost selfish -- way of thinking about one's job.<br /><br />I observed another, more subtle example recently at a company. Some developers were responsible for creating interfaces. Others were responsible for implementing those interfaces. Apart from not promoting collective code ownership, this doesn't sound so bad at first. However, when you reprimand and reward (financially and otherwise) the different individuals based on exactly how the resulting software got broken, things quickly spiral down into a finger-pointing, responsibility-avoidance culture rather than one that values collective effort towards relentless quality improvement. This is what I found at that company.<br /><br />Organizational Dysmorphia is consistent with and is a specialization of <a href="http://en.wikipedia.org/wiki/Conway%27s_law">Conway's Law</a>. Conway's Law is neutral: organizations are constrained to produce systems that mirror the communication structure of these organizations. Organizational Dysmorphia is the subcategory that deals with severely abnormal and dysfunctional instances of Conway's Law.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-42829259093205237802011-05-09T04:35:00.001-07:002011-05-09T19:00:45.343-07:00Magnanimous WriterMartin Fowler's essay on <a href="http://martinfowler.com/bliki/TolerantReader.html">TolerantReader</a> was a timely read for me, since I've been dealing with both coupling with downstream services and providing services for upstream consumers at my most recent project.<br /><br />It is nice to find on the other side of a TolerantReader a MagnanimousWriter. A writer that can anticipate and forgive some of the mistakes that readers that are less tolerant will inevitably commit.<br /><br />One way we tried to make our writer tolerant on our project was to abide by the following contract to the upstream consumers of our RESTful services:<br /><br />1. We will version our resources thus: <code>/v/1/widgets</code> etc.<br /><br />2. We will not make any incompatible changes to any of our existing resources.<br /><br /> 2.a. On a GET of an existing resource, we will never provide fewer entities than we do today, although we may optionally provide extra entities over time.<br /> 2.b. On a POST to an existing resource, we will never demand more required entities than we do today, although we may allow additional optional entities over time.<br /><br />3. If we ever need to modify our resources in a way that we cannot live by rule #2 above, we will always create a new version of our resources: <code>/v/2/widgets</code>, etc.<br /><br />One way we enforced this contract upon ourselves was through a test suite that validated our schemas. Here is a sample rspec test, (over)simplified:<br /><pre><br />describe "widgets view" do<br /> it "should match the schema" do<br /> orders = create_array_of_widgets_from_factory<br /> assigns[:widgets] = widgets # sets "widgets" variable in the view<br /> render "widgets/index.xml"<br /> rng = File.join("/dir/to/relaxng/schemas/widgets.rng")<br /> response.body.should be_valid_against_rng(rng)<br /> end<br />end<br /></pre><br />The <code>/dir/to/relaxng/schemas</code> directory had its SVN commit access control set up in a way that only a few people (tech lead, etc.) could commit to it. This reduced the risk where a pair of devs (erroneously) changed the element "price" to "cost" in both the code and tests, committed everything, verified all builds were green ... and cause massive heartache with our upstream consumers when the app was put into production.<br /><br />Of course, it is probably impossible for a writer to be magnanimous for ever. No team can support a very large number of versions of (even slightly) different versions of the same resource. On our team, we only had one version by the time I left but we seemed to be on the cusp of <code>"v/2/something"</code>. However, it was our collective understanding that before we ever went to <code>"v/3/anything"</code>, we would retire <code>"v/1/everything"</code>.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-32654776109363152472009-11-10T13:51:00.000-08:002009-11-10T21:03:17.736-08:00Congratulations − I won the lottery and you're all screwed!I have worked at several companies − both as a consultant and as a full time employee − where one key person had unshared knowledge about some critical aspect of the business. Meeting such people fills me with a feeling of foreboding. I wish I could tell the manager of such a person what I know to be true.<br /><br />"You're one resignation away from temporary operational seizure."<br /><br />It is surprising to me − although less so each time I find such a case − that more managers do not find this situation as worrisome as I do. It is not as if people haven't seen such operational seizure in reality before. It appears that the same kind of nonchalance that sanctions other reckless behavior propels managers to think "it will never happen to me; Joe will never quit on me like that".<br /><br />And yet, it happens every day in organizations small and large across the land.<br /><br />It could be that we deny the possibility of operational seizure because it is not a pleasant thought. We have to force ourselves to think about unsavory outcomes <span style="font-style:italic;">before</span> we can think about solutions. Crossing that valley of doom before we may reach any safety is perhaps too depressing for many people. However, simple refusal to consider unsavory outcomes doesn't reduce the probability of those outcomes by one iota. Positive, can-do thinking is good until we have to think about risks.<br /><br />Lister and DeMarco talk about risks at length in their book "Waltzing with Bears". The one example they give that has stuck with me is the kind of thinking most parents subconsciously do with regard to their children. We, as parents, fashion all sorts of negative scenarios in our heads − some of them quite fanciful and even whimsical − and then undertake plans to protect our children from the effects of such accidents. No one begrudges us such negative thinking; indeed watchful observers would think of us as neglectful parents if we were to <span style="font-style:italic;">ignore</span> the dangers that could possibly befall our children. Yet we fail to take the same lessons when dealing with responsibilities at our workplace. We willfully neglect possible risks, including the risk of unexpected staff attrition, when planning projects or setting goals.<br /><br />The core values of Extreme Programming; especially feedback and communication; are geared towards mitigating this risk. One of my professional goals is to help people realize the effectiveness of these values (and courage, simplicity, respect and others). I want to help create a culture where people are treasured because of the value they add by their presence, not the feared loss of value they would cause by their departure.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com1tag:blogger.com,1999:blog-259536803367168385.post-77755746744578320742009-06-29T05:54:00.000-07:002009-06-29T23:29:20.019-07:00"Tropical Tricia's Paradise" - A variant of "Werewolf"Tropical Tricia is a variant of the team game known as Mafia or Werewolf − adapted for the world of software development. This variant changes the metaphors from "village", "killing" and "lynching" to "team", "sending off to vacation" and "firing", respectively.<br /><br />A stated goal of this variant of the game − and something that sets it apart from the other variants − is to make the lines between "good" and "bad" ambiguous. This is a reflection of the real world of software development where many decisions have both passionate proponents and opponents, making simple "good" and "bad" labels insufficient.<br /><br />The following instructions are based on those found on the Portland Werewolf website (<a href="http://portlandwerewolf.com/rules">http://portlandwerewolf.com/rules</a>).<br /><br />The players represent a typical project team led by two or more project managers (Tropical Tricias) and containing several Tired Team Members. Since the team members are "tired", the Tropical Tricias want to send them to a Tropical Paradise for some much needed rest and relaxation. However, the team members − tired as they are − want to continue working and do not appreciate the concern to their well-being shown by the Tropical Tricias. To do this, they try to find the Tropical Tricias and have <i>them</i> relieved of their duties, or "fired". Other roles in the game try to discover the identity of the Tropical Tricias or zap the e-mails that Tropical Tricias send at night.<br /><br /><b>Setup</b><br /><br />The players sit in a circle or around a table, where everyone can see each other.<br /><br />You will need scraps of paper or cards containing the different roles. Each player takes a card and that will be their role for the game. It is vital for game play that no one knows what each other's role are, except for the moderator.<br /><br />An example distribution of fifteen players is two Tropical Tricias, two Speedy Sys Admins, one Daring Director, and everyone else is a Tired Team Member.<br /><br />One of the roles is a Moderator. If you are playing with a group of people that have not played before, it will be beneficial to pick a player that has played before to be the moderator, so that first time players can understand how the game is played.<br /><br /><b>Game Play</b><br /><br /><u>Night</u><br /><br />The moderator says, "Night has fallen, the office is closed. Everyone go home and off to sleep." All the players close their eyes. The moderator then asks the different roles that perform tasks at night to wake up (open their eyes), find one another, perform their tasks and then go back to sleep (close their eyes).<br /><br />Tasks consist of sending another player to the Tropical Paradise, "saving" another player from going to the Tropical Paradise, or gaining knowledge about another player. The tasks are performed by pointing to other players for the Moderator to see. The Moderator can then respond with a positive, thumbs up, or a negative, thumbs down, if the task was to gain knowledge. See the roles below for more details on their tasks.<br /><br />In order to allow all players to interact the first day, you may choose to not have the "night" players perform their roles the first night, just find each other. For example, the Tropical Tricias will choose to send someone to the Tropical Paradise every night. If they do so the first night, then that player doesn't get a chance to play during that game.<br /><br /><u>Day</u><br /><br />When the players that perform tasks at night have completed their tasks, day breaks. The moderator says, "The day has begun. We're already at work. Everyone wake up!" All the players open their eyes. If a player has been sent to the Tropical Paradise, the Moderator then says, "Player X has been happily sent to the Tropical Paradise." That player is now out of the game and is no longer allowed to say anything. As an added twist, it is recommended that the role of the player not be revealed until after the game ends.<br /><br />It is now the remaining players' time to choose a player to fire. Players can say anything they want. Deceit, misdirection, and out right lying − aka "confidentiality", "discretion" and "adherence to corporate policy" − are encouraged, especially for the Tropical Tricias. Players discuss and try to build cases for who they think the Tropical Tricias are.<br /><br />A player suggests that another player is a Tropical Tricia. The moderator then asks the other players if anyone seconds their suggestion. If there is a second, the accused then gets a chance to give their defense. Then the moderator asks for a vote, "Please raise your hand if you think player X is a Tropical Tricia and should be fired." If the majority of players raise their hand, the player is fired and is now out of the game. If there isn't a majority, then the players go back to discussing who to fire until the group comes to a consensus, they pick a fellow player to fire, and night falls again. As an added twist, it is recommended that the role of the fired player not be revealed until after the game ends.<br /><br /><u>Winning</u><br /><br />This cycle continues, night into day, day into night, until either all the Tropical Tricias are fired or the number of remaining Tropical Tricias is more than or equal to the number of remaining Tired Team Members.<br /><br /><b>Roles</b><br /><ul><br /><li>Moderator − The moderator isn't actually a player but runs the game and keeps it moving.</li><br /><li>Tired Team Member − Team member responsible to delivering the project. They work during the day and sleep at night.</li><br /><li>Tropical Tricia − A typically overworked Project Manager. A Tropical Tricia works during the day and catches up on e-mails at night. Being a good Project Manager, she picks one player (of any other role) each night to send an e-mail to, informing that player that s/he has been sent to a Tropical Paradise for some much needed R&R. That player is no longer part of the team and is free from the stresses and challenges of delivering the project. Tropical Tricia is aware that her concerns for her team members is particularly irksome to the Daring Director (whoever he may be). She's also aware that the VP (if present) can have ambivalent feelings towards her.</li><br /><li>Daring Director − A Program Director who, while respecting people's right to R&R, is overly concerned about delivering the project. As such, s/he is not completely enthused by Tropical Tricia's approach to letting people go to the Tropical Paradise. The Director wants to fire Tropical Tricia so that the rest of the team can work on the project. Each night the Director points to one player. The moderator responds with a thumbs up if that player is a Tropical Tricia, or thumbs down if they are not.</li><br /><li>Speedy Sys Admin − The Speedy Sys Admins are sick of all the e-mail traffic created by Tropical Tricias. Unfortunately, because of privacy concerns, they cannot zap all the e-mails coming <i>from</i> the Tropical Tricias. They can only block e-mails directed <i>to</i> a particular player. Sys Admins choose one player whose e-mail will be monitored each night. If the player they chose gets an e-mail from Tropical Tricia that night, that e-mail is zapped and the player gets to stay on the team, working on the project.</li><br /></ul><br /><br /><b>Optional Roles</b><br /><ul><br /><li>Office Gossip − The Office Gossip is very jealous of Tropical Tricia and wants to stop her any way she can. She can open her eyes when the Tropical Tricias are awake and sending e-mails, so she can have the Tropical Tricia fired. However, if the Office Gossip is caught with her eyes open, she herself is immediately fired because of her unethical behavior. (Variation: if the Tropical Tricias discover the Office Gossip with her eyes open, they may signal to the Moderator to spare her life on the condition that she join the Tropical Tricias.)</li><br /><li>Agile Consultant − On the first night, the Agile Consultant points to two players. Those players are considered Pair Programmers. If one of them is sent to the Tropical Paradise or fired, the other one has to go as well.</li><br /><li>VP − Each night the VP points to one player. The moderator responds with a thumbs up if that player is a Daring Director, or thumbs down if they are not. The VP may choose this information to either back the Daring Director's attempts to fire the Tropical Tricias, or the VP may choose to fire the Daring Director himself and side with the Tropical Tricias. (Variation: The VP may open his eyes when the Tropical Tricias are awake and signal to them that he is siding with them with a "V" signal. Of course, he may be just "following company policy" when he says that ...!)</li><br /></ul>Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-50380473816725721472009-06-04T16:14:00.000-07:002009-06-04T16:33:43.189-07:00Net Nastiness and Road RageA couple of years ago, Martin Fowler wrote about <a href="http://martinfowler.com/bliki/NetNastiness.html">Net Nastiness</a> in his usual lucid style. His recommendations about "[making] our communities the kinds of places we want to be in" is true for all communities, perhaps especially so for online-only communities, which have no other means to rescue themselves once pervaded by Net Nastiness.<div><br /></div><div>I believe there are some parallels between Net Nastiness and Road Rage.</div><div><br /></div><div>1. Both happen when the offender feels physically secure from retaliation (the security of a vehicle, the security of anonymity on the Internet)</div><div><br /></div><div>2. In both forms, the offender is unaware of the personhood of those he is offending. Often, their personhood is erased by using an impersonal epithet to refer to them ("the beige jalopy", "the @JavaNewbie")</div><div><br /></div><div>3. In both forms, the interaction between the offender and those offended is fleeting, with a very low probability of any further interaction in life</div><div><br /></div><div>After recently becoming the unwitting subject of a bout of NetNastiness on Twitter, I realized that for micro-blogging sites, these parallels hold even more strongly than for the more traditional blogs and wikis. In the noisy world of Twitter, spewing a short insult like "@ThatUser is a bumbling idiot!" is the online equivalent of cutting in front of someone, flipping them the bird and then taking the next exit on the highway.<br /></div><div><br /></div><div>While I'm not sure what's the right way to reduce Road Rage, as far as reducing Net Nastiness is concerned I believe following Martin's suggestions is valuable, nay, necessary. By speaking up, contacting administrators, flagging inappropriate posts (where the technology allows it) and switching away from chronically nasty communities; we can make the Internet a more enjoyable, informative and habitable place for the vast majority of us.</div><div><br /></div>Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-45249520914101232472009-06-01T07:26:00.001-07:002009-06-01T08:14:59.677-07:00(Re)Thinking FunctionallyLast Saturday, I attended the very vibrant and well-put-together <a href="http://www.chicagocodecamp.com/">Chicago Code Camp</a>. A couple of the sessions I attended were by <a href="http://www.deanwampler.com/">Dean Wampler</a>. They were both about Functional Programming (in Ruby and Scala, respectively). <div><br /></div><div>To me, the most significant transition towards functional languages is the art of thinking functionally. Or, re-thinking functionally − since when I started programming, C was the rage and functions were all we had. Thinking back, we <span class="Apple-style-span" style="font-style: italic;">could</span> have used function pointers as explicit implementations of closures (sort-of) rather than as a hack towards creating poor-man's-C-objects (= structs and its related functions in one C-file).</div><div><br /></div><div>I suppose we were young then. Some of us, at least (the ones who were writing code in late 80s / early 90s, that is). We, who had grown from writing assembler code to the (slightly) more abstract syntax of C, followed the evolution of C-like languages.<br /></div><div><br /></div><div>It so happened that C (with functions and function pointers and structs) evolved towards C++ (with classes and objects) rather than towards a true FP language (with true closures − and perhaps a canonical implementation of lambda calculus). </div><div><br /></div><div>Which brings me back to my current challenge. After having spent the last 15+ years not only viewing the world around me in terms of classes and objects but also <span class="Apple-style-span" style="font-style: italic;">thinking</span> that way, it takes some effort to (re)start thinking in terms of functions. </div><div><br /></div><div>Powerful analogies can help (or hinder) this transformation. For me, the turning point towards "thinking-in-objects" was when a college professor analogized the breaking of a glass when it hit the stone floor (but not when it hits a rubber mat) as the different interactions between the glass object, the floor object and the rubber mat objects:</div><div><br /></div><div><span class="Apple-style-span" style="font-family:'courier new';">shards = glass.strike(stone-floor);</span></div><div><span class="Apple-style-span" style="font-family:'courier new';">glass = glass.strike(rubber-mat);</span></div><div><br /></div><div>I suppose I should restart thinking in terms of (pseudo) lambda function which transform the glass into either shards or the glass (= identity function) depending on the parameter:</div><div><br /></div><div><span class="Apple-style-span" style="font-family:'courier new';">F(m)(n) = shards, ∀ m ∈ {glasses}, n ∈ {stone-floors}</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"> = m, ∀ m ∈ {glasses}, n ∈ {rubber=mats}</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"> = undefined, otherwise</span></div><div><br /></div><div>I've been up this hill before, although it'll still take some effort to get to the summit again. I am happy and excited to be able to undertake the journey. </div><div><br /></div><div><br /></div>Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-66343991217942436092008-12-26T09:16:00.000-08:002008-12-26T09:48:28.738-08:00Cargo Cult Agile AdoptionI've seen the following scenario unfold at two different clients:<br /><br />1. Initial enthusiasm to go Agile, driven by an executive mandate.<br /><br />2. A mix of eagerness shown by some delivery people (devs, QA, analysts, PMs etc.) and resistance by others.<br /><br />3. Growing friction between the two factions, inducing the executive management to create layers of Oversight Committees, PMOs, Steering Groups, Agile Coaches / Coordinators / Evangelists / Czars / Sensei / Black-belts -- and other holders of titles culled from clergy, industry and fantasy.<br /><br />4. Adoption of the easier Agile habits: story-walls, open work-spaces, iterations (sometimes not time-bound) and stand-ups (sometimes modified to sit-downs).<br /><br />5. Assiduous proclamations of the merits (equally often, the demerits) of the harder Agile practices: independent stories, independent estimates, TDD, CI, automated test suites, tracking delivered business value (using PM tools appropriately) and continuous customer collaboration.<br /><br />6. Permeation of a snarky disbelief throughout the organization in the viability and usefulness of Agile practices.<br /><br />7. Recidivism to the previous state of suboptimal software delivery, while retaining the glittery Agile titles: people, processes and productions glow with the newly acquired veneer of Agility while losing none of their inner fragility. I've seen 40 minute long meetings (with less than 10 attendees) conducted in the name of a "stand-up".<br /><br />This scenario -- which I dub Cargo Cult Agile Adoption -- reveals a belief that simple mimicking of some externally visible Agile practices will somehow create the values that underlie those practices.<br /><br />The ritual of having a card-wall cannot create even an illusion of communication, if the will to communicate openly is not there. The ritual of creating a CI server cannot substitute for the values of courage and simplicity -- the CI build will probably be either mostly broken, or developers won't commit any code for days for fear of breaking a brittle build. Rituals and practices are merely the expression of underlying values, they cannot cause those values to exist out of nothing.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-14336930182495156582008-08-31T07:43:00.000-07:002008-08-31T08:31:01.915-07:00Test Driving the "Money" exampleThe other day, I demo'ed Kent Beck's "Money" example in a Lunch and Learn session.<br /><br />Even though participation was very thin (for a variety of scheduling challenges), the people who did attend found the session useful. This was heartening.<br /><br />I test-drove the "Money" example equivalent to the first 11 chapters of Kent Beck's book [1]. There were some variations: I added a test-for-instanceof-based-equality, asserting that a ClassCastException was thrown when Dollars were compared to Euros. Later, when the instanceof operator in the equals() method was replaced with the domain concept of "currency", I test-drove this change by modifying the test-for-instanceof-based-equality to a test-for-currency-based-equality. This new test asserted that no exceptions were thrown when Dollars were compared to Euros.<br /><br />The other variations dealt with the natural ebb and flow of the demands of an eager (though small) audience: I took detours -- even to dead-ends -- to answer questions and demonstrate principles. I allowed the audience to direct some of the refactorings: we replaced the calls to Dollar() and Euro() constructors with calls to factory methods in Money class much earlier than in the book, based on their familiarity with the principle of separating creation of objects from their usage. And, of course, I made the example more contemporary: I replaced Francs with Euros. This latter change had the effect of inverting the exchange rate from 1 Dollar = 2 Francs (in the book) to 2 Dollars = 1 Euro; which is a fairly close approximation of current reality.<br /><br />The feedback from the small audience was generous: it was mostly 4's and 5's (on a 5-point scale, 5 being highest). I would have liked to do it differently (and hopefully better) in the following ways:<br /><br />1. Test Driving all the way to the end of the Money example. This corresponds to chapter 16 (chapter 17 is the retrospective). I believe I'd have needed about 20 more minutes to do these five remaining chapters.<br />2. Demonstrating code coverage more often. I switched to the Eclemma coverage window not often enough.<br />3. Being more deliberate and thoughtful (rather than speedy and mechanical) in test-driving some of the changes.<br /><br />I do realize that even the items on this short wish-list have built-in conflicts. But then, crafting software is all about finding serene compromises amongst conflicts.<br /><br />[1] <span style="font-style: italic;">Test-Driven Development By Example</span>, by Kent Beck<span style="font-style: italic;"> </span>Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-40525123145616803442008-08-31T06:32:00.000-07:002008-08-31T07:23:42.265-07:00No Integration Without RepresentationThis article is not about the European Union.<br /><br />Much has been written about the dangers of integrating software components late in a project. "Late" could mean "not at the first opportunity", "not after every working change to every module" or "closer to the product's deployment date than the project's commencement date". Any definition suffices for the purpose of this article.<br /><br />One reason that exacerbates late integration is that not all the software systems that need to be integrated with the system-under-development (SUD) are known in advance. This problem is (in software terms) ancient, and apparently bit the first XP project -- "end to end is farther than you think". [1]<br /><br />It is always going to be difficult to a priori enumerate the complete list of software systems with which a given SUD is going to integrate. And such a list would be an evolving artifact, anyway. So how do we continually determine with which systems our SUD is expected to integrate?<br /><br />One way is to make this apparent by representation. Most iterative teams regularly present their evolving product to the customers and stakeholders -- usually at the end of each iteration. This is a natural junction where integration points with other systems can be demonstrated.<br /><br />How do we know if we're missing some key integration point(s)? Expand the membership of the "iteration showcase" meeting to representatives of external system who <span style="font-style: italic;">might</span> have an integration point. It may seem chaotic to invite too many people to an iteration showcase, but in practice this works out well. Quite often, such "chickens" either quickly transmogrify into "pigs" or leave the roost.<br /><br />The foil to this wishy-washy "come if you're interested, don't if you aren't" is the statement "you probably <span style="font-style: italic;">are</span> interested if you use an application that consumes data from or provides data to this SUD". I like to condense this to the pithy "no integration without representation".<br /><br />Explicitly proclaiming that the SUD will integrate with all (and only) the applications whose stakeholders are represented has a self-correcting effect on guiding the integration points. Of course, encouraging, enabling attendance, and welcoming the representatives who <span style="font-style: italic;">might</span> have an integration point are all necessary to the correct usage of this pith.<br /><br />[1] See the "Creation Story" in <i>Extreme Programming Explained</i> by Kent Beck.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-2803640528138125502008-06-28T20:56:00.000-07:002008-06-28T20:57:17.258-07:00Another reason for TDD<p>It seems that one can never have enough good reasons for espousing Test Driven Development (TDD). If there is a dearth of cogency in this argument, then I hope the following helps.</p><p>One way to think about a robust test suite is that it is something akin to a safety net against creating unsafe software. The definition I have in mind is coincident with what Donald Norman calls a "forcing function", and is sometimes referred to as Poka-yoke.</p><p>Consider a kitchen appliance such as the food processor. To run the food processor, you must assemble the various parts in a precise way. Consider just the lid for the moment. Not only must you lock the lid in place; it must also unlock the hidden safety switch with the projecting cam (see figure).</p><p style="text-align: center; clear: both;" class="separator"><a style="border: 0pt none ; background-color: transparent; margin-left: 1em; margin-right: 1em;" href="http://pages.google.com/edit/siddiqui.saleem/lid.jpg/lid-full.jpg" imageanchor="1"><img src="http://pages.google.com/edit/siddiqui.saleem/lid.jpg/lid-full.jpg" style="border: 0pt none ;" /></a></p><p>If the cam is broken, then the food processor will not run, even if the lid fits snugly on the bowl. While it can be distressing if the cam breaks during washing the lid in the dishwasher; the cam provides a forcing function, preventing unsafe operation of the food processor.</p><p>TDD can be looked as a practice of providing a comprehensive forcing function for software. If the tests are broken, the software will not run (would not build in most cases). It can be vexing when the build breaks because of failing tests, but the tests prevent producing unsafe software.<br /></p> So the next time someone complains about tests failing builds, politely ask them if they'd like to use a blender that ran with or without the lid.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-53275911713206432802008-06-28T20:50:00.000-07:002008-06-28T20:52:04.637-07:00Upgrades and Shovegrades<p>Quite often, you feel that you really don't need the new version of a certain piece of software; but you really don't have a choice. You simply cannot keep working with the old version -- the decision is not yours to make.</p><p>This is not a Luddite argument. Technological progress is eventually inevitable -- even change (as opposed to progress) is a fact of life. However, when bad change is thrust upon unwilling and unsuspecting users, it is at least proper to call it by its correct name: a shovegrade.</p><p>Perhaps the neo-classical example of a shovegrade <i>outside</i> the software world is the so-called <a href="http://en.wikipedia.org/wiki/New_Coke">New Coke</a>. What made it feel like a shovegrade was not just that it was a "change", nor only that it was "unsolicited"; nor that it was "compulsory"; nor that it was "less appealing" -- but that it was all of those at once.</p><p>This gives us a fair working definition of a shovegrade: <i>An unsolicited compulsory change which results in a product that is less appealing than before</i>.</p><p>In software , many upgrades are in fact shovegrades. The reason this is prevalent in the software world is because it is relatively easy to retire one version and move to the next. License keys (especially those managed through a central license server), <a href="http://en.wikipedia.org/wiki/Time_bomb_%28Software%29">time-bombs</a>, deactivation of online support accounts, version management through <a href="http://en.wikipedia.org/wiki/Push_technology">Push Technology</a> -- all these make it possible to forcibly shove new versions of software instantly down<br />the collective throats of all consumers.</p><p>I experienced recently an example of a shovegrade on a large project. The architecture team (to which I did not belong) created a new API to handle the concept of Time and shoved it down the throats of all other teams (including the one to which I did belong). The real implementation problems this new Time API caused were unanticipated by the architecture team. Since the old implementation of Time had been <u>removed</u> (not deprecated), and the new API failed to deliver key "-ilities" (reliability, simplicity and others); this felt like -- and was, by my definition above -- a shovegrade.</p><p>The underlying fact -- that the architecture team failed to anticipate the problems caused by the new API -- was due to their lack of involvement in the design and implementation of the domain solution. In one sense, this is a lack of application of the<a href="http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ArchitectAlsoImplements"> Architect Also Implements</a> organizational pattern.</p>That is a topic best handled elsewhere.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0tag:blogger.com,1999:blog-259536803367168385.post-72286900626291172912008-06-28T20:43:00.000-07:002008-06-28T20:44:35.901-07:00FrontispieceThis blog lists my musings on software.Saleem Siddiquihttp://www.blogger.com/profile/00817037816641469786noreply@blogger.com0