Day Dream Dinner
In a day dream, I met a genie. He kindly offered to setup my dream dinner for me. All I had to do was name six guests and they would receive gilt invitations to the best restaurant in the world. Of course, they would all be delighted to attend and would be spared the nuisance of travel arrangements by handy magical teleportation. I hesitated for a moment, there are so many people that I would like to name. The genie tapped his foot impatiently. Alright here they are:
Who would you name?
The Software Bathtub Curve
I have had my Dualit Toaster for close to 19 years now. It has never broken down. It has reliably toasted my bread every morning with the mere turn of a dial.
I have had my dishwasher for 1 year and 2 weeks. It has all sorts of cool buttons and modes so that I can customize my wash cycles to suit my dishes and my mood. Precisely two weeks after the warranty expired, it began to blink randomly and stopped working. The control board had died. This was not an isolated incident. I have gone through many such failures with other appliances, my refrigerator, stove and washing machine.
Looking at my toaster and dishwasher, I made a couple of observations:
- The more complex the product, the less reliable it is, and the shorter the life span.
Sure, it would be cool if I could control my toaster with my mobile phone app, but just having a heating coil and a dial gives the advantage of having a lot less things that could go wrong.
- A product is only as reliable as its least reliable part.
You can pay a small fortune for a oven built of stainless steel with all the latest technological advances in color display and computerized air flow. But if it relies on the same computer circuit board that all the other ovens use, (the one gives out after a year), then your investment is not any more reliable.
I also noted that these observations could be translated to software as well. Certainly, in the case of building software, the more complex the system the more things that can go wrong. The same could hold true that overall software system is only as reliable as the least reliable part of it.
This brought me to the larger question.
How can they predict the dates so accurately? My dishwasher stopped working 2 weeks after the warranty ran out.
— Carin Meier (@carinmeier) April 11, 2012
How do the manufacturers know, with such accuracy, when the product is going to fail? Could you apply the same principles to software?
@carinmeier believe it or not they spend millions calculating it. I spent way too many hours in 6-sigma training with bathtub curves.
— Jonathan Hays (@cheesemaker) April 11, 2012
The Bathtub Curve, according to wikipedia, is widely used in reliability engineering. It gets its name from the shape of the curve, which looks a bit like a bathtub. It is talked about in three sections:
- Decreasing failure rate (early failures)
- Constant failure rate (random failures)
- Increasing failure rate (wear-out failures)
With software, we don’t talk about failures so much. We do talk about bugs, but even that is a bit misleading because it doesn’t take into account the need to accommodate features and evolving changes. So let’s talk about “issues” instead that can be broad enough to accommodate traditional bugs, gaps of functional needs, and performance related items.
The Software Bathtub Curve might look like the following:
Decreasing issue rate (launch & growing pains)
This is the early stage of the software. After its initial launch, gaps in functionality, bugs, and performance issues are readily identified and corrected. The main factors of reliability here are communication, responsiveness and agility.
Sample questions for determining data for this part of the curve:
- Do you use a dynamic language/ framework that allows rapid development? +10
- If the product owner and developers were in the same restaurant would they recognize each other? + 10
- Can the product owner and developers recognize each other by voice? +5
- Do you have a daily standup? + 5
- Do you really stand up the whole time? +2
- How many outside integration points are there? -5 for each
- How many programming languages and frameworks are there? -5 for each
- Do you release often? +5 for every 2 weeks (-1 for each week longer)
- Do you work over 40 hours a week regularly? -10
- Do you have an automated test suite? + 10
- Does it have regularly have untended errors in it? -5
- Do you use pair programming or code reviews? +10
Constant failure rate (random failures)
This is the time when the software reaches maturity. The business needs do not change drastically, but require minor refinements. Random issues occur from 3rd party integration issues or real world data issues. Major factors for reliability in this phase are avoidance of technical debt, data curation, and code quality.
- Has the team scaled down to just include a minimal or junior support staff? -10
- Do new features/ fixes get put in with the appropriate refactoring and tests? + 10
- Do new features/fixes more often just get stuck in there in the easiest way possible? -5
- Do your tests still all pass +10
- Do you get advance warning when a 3rd party api is changing? + 10
- Do you test that change in advance? + 5
- Do you still talk to the product owners? +5
- Do you care about code / data quality? + 10
Increasing failure rate (Failure to adapt to new business needs)
This is the final phase in the software life cycle. The new business needs cannot be met with the exsiting software and the cost of changing or adapting it is too high or not possible. Major factors for reliability and length of life span include openness and complexity of design and architecture.
- Do you have have to pay for a closed vendor product? -10
- Do you use open source languages and libraries? + 10
- Are you afraid to change anything because it might break? -10
- Is your main software language more than 1 version behind the latest? -5 for each version behind
- Does the mention of new features install fear instead of passion? -500
In the end, although it is interesting to compare software to the appliance Bathtub Curve, it is a leaky abstraction at best (sorry, couldn’t resist). Software is living thing. It needs to respond to its ever changing environment and needs. Furthermore, it is made up of a collection of living people who care and tend for it as well. However, there are clear factors that can go a long way to increasing the reliability, usability, and lifespan of software as well. We, as software developers, should keep them in mind as part of the ultimate goal of creating living, quality software.
I hit myself in the cheekbone the other night when I was sleeping. No really, the boring truth is that I was pulling the blanket out from my underneath my nice, but rather big and heavy dog and my hand slipped and I whacked myself in the face. Being hurt, pissed off and half asleep is not a very pretty place to be. On top of that, when I dragged myself to the mirror the next day, I saw I had a lovely red bump which then had the audacity to grow even larger and turn purple the next day.
I attended a get together of women friends and family that night. I was a bit self conscious, but they all knew me. But still, I had to deal with a barrage of well meaning questions about what happened to my face.
- “Oh my gosh, what happened.. “
- “Poor thing, it looks like it hurts …”
- “You should put ice on it.”
- “You should put heat on it.”
- “Did you see the doctor about it yet?”
Don’t get me wrong. I am glad that they all took an interest in my well being and care about me. But since it was an embarrassing incident, I did really not want to dwell on it. I mean, if it had happened when I was fighting vampires, it would be a different thing entirely.
So, with that incident behind me, I steeled myself for the office the next day. The office is about 15 men and just one other female.
This is the reaction I got:
- “Man, this Rails upgrade sucks.”
Awesome.
Code Mash 2012: Bacon for the Brain
I was delighted to see first hand, why 1200 CodeMash tickets sold out in 20 minutes. It was full of awesome. This was easily the biggest conference that I have ever attended. It was held in the luxurious and fun Kalahari conference center and ran as smooth as silk, expertly supported by a volunteer staff.
One of the things that I really appreciated about the conference was the diversity of people from different technology backgrounds. There were many developers from .NET, Java, Ruby, and Python worlds all coming together to swap stories, share ideas and learn something new. It created an opportunity for everyone to get out of their box and their comfort zone. I was particularly impressed by one woman that I talked to, who came from the .NET world but had made a conscious decision to not attend any .NET talks at all.
The talks that I attended were all superb. Here is a few of my personal highlights:
- Jim Weirich’s Roman Numeral Code Kata: He did a live coding demonstration of the Roman Numeral kata by TDD and refactoring. The joy that he shows when his tests turn green and the love of the beauty of the code that emerges from refactoring, embody for me what Software Craftsmanship is all about. He simply is an inspiration.
- Joshua Smith’s Prolog Talk: An excellent talk by and excellent speaker. He demonstrated the basics of Prolog reasoning by doing a family tree example. I am intrigued by it’s use with Semantic Web RDF reasoning and it’s similarity to Clojure’s core.logic. It is top of my list of things to look into.
- Jen Myer’s Developers Can’t Design: She touched a chord for me, since I wish that I had more design skill. She masterfully pointed out the similarities of solving problems in design just as we solve problems in code development. Another key take away for me, was the need to have a holistic design for our applications. Siloing designers in Photoshop and then having developers take it from there is reminiscent of failed waterfall patterns. Embracing holistic design feedback at all levels of the project is needed to produce excellent applications.
- Elizabeth Naramore’s Building Open Source Communities: This talk was a gem. She touched on the importance of Open Source communities by focusing on it’s essential component – people. Communication is so important in facilitating the flow of ideas that turns into the magic that fuels a vibrant community. One of her points, that I took away is to remember it is the little things that count. Don’t forget to say “Thank you.”
Another thing that delighted me was the strong interest in Clojure that was present at the conference. I had the good fortune to present an introduction to Clojure and I was so happy to talk to many people during the conference that said that they were interested in learning more at the language. There was even an Open Space that got spontaneously organized on Clojure on Friday.
The only downside of the conference was that it was hard to choose between the Open Spaces and the excellent talks going on. I did attend one that Justin Searls hosted on Friday afternoon. It was a blast. People paired up creating a simple JavaScript To Do app from different frameworks. John Andrews and I took the opportunity to explore ClojureScript. In particular, we played around with the new ClojureScript One and also the Enfocus library. At the end of the hour, we were having so much fun, I wished that we had another day just to continue.
All in all, it was an awesome time and I recommend it highly. If I had to sum it up in a phrase it would be: Bacon for the Brain :)
Getting Ready for CodeMash
Only one more day until CodeMash. I am really looking forward to my first one. I have heard nothing but wonderful things about this conference that brings together developers, geeks and their families for a week in January in Sandusky, Ohio.
I am also looking forward to the opportunity of presenting my “Once Upon a Time in Clojureland” talk. It is an introduction to Clojure in a Fairy Tale format. I am hoping to share my enthusiasm for the language and inspire others to try it out for themselves.
If you haven’t seen it, you should check out the Mashed Code Magazine. It is full of awesome. It also contains a piece that I wrote under my super secret identity. Hint, it is about Monads :)
Well off to pack and get things organized. I’ll post my full coverage in the following days …
Nyan Cat Country Technology Index
Nyan Cat
One important measure of a country’s economy is it’s technology. Most current technology indexes for countries rely on boring statistics like R&D spending and internet availability. I think that these measures are totally inadequate. To really gauge whether a country is technologically advanced, you need to take a hard look at stupid, pointless, and amusing things produced on the internet.
As an alternative, I would like to announce the Nyan Cat Country Technology Index. For those of you who have not heard of Nyan Cat. It is a internet meme that combines a flying Pop Tart cat trailing rainbows and a strange Japanese song.
Nyan Cat is a perfect example of stupid, pointless, and amusing. What’s more, it has spread like wildfire and infected many countries, resulting in various inspired patriotic versions of the video. This perfect storm of elements have combined to yield a striking new perspective of national technology.
I have used my expert experience in Nyan Cat, honed after many days of bombardment in our Campfire room at work, and my own quirky taste, to view and judge the countries that were prominent on YouTube.
Nyan Cat Country Technology Index
- Tied: US & Japan. Come on they started the whole thing. Of course, they are first.
Original Video - UK : Scottish and Irish Nyan Cats moved the UK to the 2nd place. They are superb. Notice the folded ears on the Scottish Nyan Cat. Britan could have tried harder.
- German Nyan Cat
- French Nyan Cat- Extra points for the wine and Mona Lisa. Music missing Nya
- Polish Nyan Cat– Love the Hussar wings – but points off for no Nya music.
- Dutch Nyan Cat– Again, nice rain but wrong music.
- Hungarian Nyan Cat– Nice music .. but not really a cat.
- Russian Nyan Cat
- Australian Nyan Cat
- Canada Nyan Cat
- Indian Nyan Cat
- Philipppine Nyan Cat
- Chinese Nyan Cat
- Belgium Nyan Cat
- Greek Nyan Cat
If your country was not included on the list. By all means, go out a create a video right away. Your nation’s future is depending on you. If your country has a Nyan Cat video on YouTube and was not included, I apologize on behalf of all the brain cells that were killed in assembling this list.
Addendum: I have to admit that the Nyan Cat has grown on me, especially since my office mates have turned off their Campfire sounds. I am hereby editing the post to remove the annoying adjective, but the stupid, pointless and amusing adjectives remain :)
Sunday Afternoon on the Island of La Grande Jatte painted by Georges-Pierre Seurat in 1884 – 1886.
White: a Blank Page or Canvas.
As I spent a pleasant Sunday outside doing yard work, songs from one of my favorite musicals, “Sunday in the Park with George”, came to mind. While the songs were playing in my head, my thoughts again drifted to one of my favorite programming languages, Clojure. To my surprise, I was struck by similarities between the musical, which is about the artist Geroges Seuret and his creation of one of his famous painting, and that of the functional JVM language of Clojure. Granted, musicals, art and programming languages don’t generally get discussed together, but please humor me and let me elaborate. Following the thread of my inspiration, I will be using the first few opening lines from the musical as my headings and guides for my discussion.
Let’s start with the broad subjects of Art and Software. They are both created. We use our tools, palettes and techniques to create representations of the world. The visual artist portrays this representation in paints and on canvas, while the software developer uses programming languages and computers.
Looking back in time, we see that there are many different styles of painting that have developed over time. From flat, idealized Byzantine Art to that of the incredible realistic detail of Renaissance Dutch portrait masters. These styles were a reflection of not only the techniques and materials of the time, but also an outlook on the world and the way the artist represented it. Likewise, software styles also have differed over time. From the procedural BASIC language to the current dominant style of Object Oriented programming, the styles are a reflection of not only the technology available to us, but in the way that we model real world concepts and processes into the digital space.
The Challenge: Bring Order to the Whole.
Georges Seuret was interested in the optic effect when two small points of different color placed close to one another, would seem to create a third new and luminous color when viewed at a distance. He innovated a technique called pointillism, and created a whole painting composed of tiny dots of color. The striking effect of this can be seen in his famous, large scale painting titled “A Sunday Afternoon on the Island of La Grande Jatte”.
In his use of pointillism, Seuret turned to simplicity to create order and achieve complexity. By breaking the painting down into the essence of dots of colors, he opened the way for a sort of parallelism in color viewing by the user, which ended up giving the viewer a perception of richer colors. This very technique, enhanced by todays technology is of course the basis of our incredible RGB viewing in our televisions and monitors.
Let’s turn to Clojure. Clojure is a functional language that is interested with concurrency. It also turns to simplicity to achieve complexity. By breaking things down and simplifying to more pure functions with immutable data structures, it make the complex problem of parallel programming possible. This is something that is very hard in the Object Oriented world view programming model. In my opinion, Clojure’s approach to concurrent complexity with simplicity is an important innovation to our world of software, just as pointillism was to the world of art. To better explain, let’s walk though some of the language features.
Through Design
Rich Hickey designed Clojure as a general-purpose language. He wanted it to combine some of best parts of a scripting language – the approachability and interactive development with a REPL – with an infrastructure that would be fast, robust and support multithreaded programming.
Composition
The language itself is a LISP. It gains the benefits of the simplicity of syntax of the code as data as well as having the power of Macros that allows one to customize the language. The beauty of this simplicity and conciseness allows one to focuses more on the code that matters.
Tension
Pure functions and immutable state is great, but to most things you will need some sort of state. Clojure also provides ways to use mutable state and still support correct multithreaded designs. It uses Software Transaction Memory System and Agents to achieve this. This use of mutable state in a controlled and isolated way, allows clean, efficient and concurrent programming.
Balance
Clojure embraces the JVM as it’s platform. This pragmatic approach gives not only gives the language a scalable, proven run time environment, it also gives it the advantage of accessing Java’s many mature libraries through wrapper free interoperability.
Light
Clojure language is a joy to learn. Being concise and a LISP, is very regular in it’s syntax. There are only a few key data structures and forms to learn to really get started.
and Harmony.
Clojure has an awesome community. The level of enthusiasm and innovation among the Clojure open source developers is inspiring. Every day seems to bring a new development or contribution. There is ClojureScript for JavaScript development, Noir for web development, Logic programming just to name a few.
In summary, innovation in art and technology can come through a quest for simplification. This very act of simplification, then allows for breakthroughs in complexity. Both Seuret and Hickey have shared in this vision in both their art and software.
Finally, I highly recommend watching “Sunday in the Park with George” if you haven’t seen it yet. I also highly recommend looking at Clojure too. In fact, you might want to try some Clojure Koans before watching the show. You might enjoy it from a different perspective…
Long ago, I worked for a couple years as a professional ballet dancer with a small company. Reflecting on this, I have an interesting perspective of working in field were woman are the majority and also one where women are in the minority. I thought I would dedicate this post a few observations of similarities between men in ballet and women in software development.
Men in Ballet
http://www.cballet.org/about/dancers/principal/amador
- Have some lame people think ballet is just for girls and make assumptions about them based on cultural stereotypes
- Have to have a sense of humor to handle accidentally injuries due to kicks or slips while rehearsing choreography with women.
- Clearly love what they do. Otherwise, they most likely would have never overcome the social pressure to pursue their craft.
- Partner when ballerinas to create great performances. The diversity of having men and women dance together allows more freedom of expression in the choreography. Ultimately, that produces a show that is more valuable and pleasing to the audience.
- Usually have no wait in line for the men’s restroom during ballet performance intermissions.
Women in Software Development
- Have some lame people think software development is just for boys and make assumptions about them based on cultural stereotypes.
- Have to have a sense of humor to handle accidental insensitive remarks due to slips in conversation when working with men. (Ex: hot chicks, rude jokes, etc….)
- Clearly love what they do. Otherwise, they most likely would have never overcome the social pressure to pursue their craft.
- Partner with other software developers to create great software. More diversity*, allows more freedom of expression in understanding and applying technology to solve business needs. Ultimately, that produces software that is more valuable and pleasing to the business and user.
- Usually have no wait in line for the women’s restroom during technical conference breaks.
Since joining EdgeCase, I have shelved my heavy Intellij and Eclipse IDEs in favor of Emacs. Overall, I have enjoyed moving to the light-weight but powerful editor. There is one thing that I did miss from my IDEs – that was the ability to search projects for string occurrences and being able to click navigate to them through the editor. Fortunately, one of the strengths of Emacs is it’s infinite configurability and extensibility. Even more fortunate, one of the guys in our shared office, Doug Alcorn of Gaslight Software, had already written just this feature for his Emacs. I installed it and was so pleased with it, that I thought I would share …
https://github.com/dougalcorn/emacs.d/blob/master/site-lisp/misc/project-grep.el
To install:
Download project-local-variables.el and project-grep.el
In your init.el file: (require ‘project-grep)
Create an empty .emacs-project file in your directory
To use: meta-x project-grep
Project-grep
Semantic Web and JRuby
I got the chance to share my enthusiasm for two of my favorite technologies at JRubyConf by giving a presentation on Semantic Web and JRuby. It was an excellent experience. I was able to connect with other people that shared my interest in the Semantic Web and some that have even worked with the technologies professionally. Most exciting, I had the opportunity to share my knowledge and hopefully inspire others to look farther into using JRuby with the Jena Semantic Web Framework.
Here are some resources from the presentation that I wanted to share with everyone:
On github, https://github.com/gigasquid/jruby_semantic_web_examples, I put together some examples of SPARQL queries against dbpedia as well as translating the examples that they have on the Jena RDF API to use JRuby
Here is the presentation itself:
https://github.com/gigasquid/Presentations/blob/master/SemanticWebJRuby.pdf
A special note of thanks to Brian Sletten, the Semantic Web guru, who inspired and exposed me to the Semantic Web, helped me out by answering my questions and pointing me in the right direction and for just being a swell guy.
