Sunday May 20, 2012
The most important agile practice?
As a coach, I've gone into numerous environments with the intention of introducing agile. Of course, I always talk about the values and the principles. Of course, I try to help people to see that there is no one true agile. There's no prescribed set of practices that once followed earn you the agile merit badge.
At the same time, these teams need something concrete. What things can one do in order to set them on the path to "being agile"?
Where do we begin?
There are so many practices to choose from, where does one start?
You could pick something easy and generally unoffensive to anyone on the team and start there. Continuous Integration is often a good place to start when you're looking for something nobody is threatened by. Or perhaps you could identify some of your more troubling areas and try to tackle those. This is more risky, but can give rapid and significant return.
I've seen a lot of coaches take approaches such as these. And I've seen them work well. I've done it myself.
But over the years, I've come to value one agile practice as a solid starting point over all others…
The Retrospective
Change is highly stressful. Even positive change, such as a marriage or a better job or the birth of a child, adds stress to our lives. Most of us prefer to avoid stress, especially stress that does not bring positive results in exchange for the angst.
Retrospectives foster continuous improvement. They provide us an opportunity, every so often, to reflect and assess. Well (and regularly) executed retrospectives provide a framework for determining when we need to make adjustments to how we operate. They provide every team member an equal chance to speak their mind. They are time dedicated to how in the midst of a general focus on what.
Resources
I intend to write more about retrospectives over the course of the next few weeks, but I've nothing to say that hasn't already been said quite well by others. The following are a few sources I've found useful. Please feel free to comment with other resources you've found particularly helpful.
- Agile Retrospectives: Making Good Teams Great
- Agile Retrospectives: A Primer
- The Retrospective Prime Directive
- The Retrospective Wiki
- Mark Levison on Agile Retrospectives
By: Michael Norton on: 2012-05-20 15:51:51 at: http://www.docondev.com/2012/05/most-important-agile-practice.html
Thursday May 17, 2012
Programming as a Foreign Language
In both high school and college, I took several French courses. But I’ve never been to France. I’ve never been immersed into a French-speaking context, and therefore, I never achieved fluency in French. Decades later, I can still pick out French words, I can still understand phrases and sentences, and express a few ideas, but for the most part, my knowledge of the French language faded very quickly, and almost entirely when I stopped studying.
A few years after college, I started learning another language. This language was for computers, and it’s called Java. I read Java for Dummies, which I found at Barnes and Noble. I got to the point where I could make the compiler happy, and I could make widgets appear on the screen. But due to the purely independent nature of my studying, I was never immersed in the Java-speaking context. I never got over the hump and achieved fluency.
A year later, I started learning another programming language. It’s called Perl. I was working at “dot-com” startup as a HTML and content editor, and was handed The Camel Book by the company’s CEO when he effectivey told me to learn Perl or lose my job. I got to the point where I could print stuff onto the screen and execute programs. And then the CEO and CTO gave me fake CGI projects to work on in my spare time. When I quickly cranked those scripts out, they started giving me bugs to fix in the main product. I had no clue what to do next, so I asked the CTO for help. The CTO gave me a quick lesson on debugging, but I was still at a loss for how to fix bugs in our product code.
I had learned French and Java, but I’d never been immersed in them. I had now learned Perl, and the opportunity to immerse myself into a Perl-speaking context was available to me. I asked if I could move my desk to where the programmers worked. The people I’d been sitting near were talkative, energetic, and the space was bright. The developers kept their workspace dark, and they were intimidating to me. But I couldn’t think of any other way forward than to immerse myself into their land of Perl.
A few months later, I was fixing bugs. A few months after that, I was at another company writing more complex scripts. All along the way I was surrounded by people who were fluent in Perl. A year later, I was fluent in Perl. Two years later I was fluent in Java and Ruby.
Just as with spoken languages, achieving fluency in a programming language requires immersion. Once fluency is achieved, similar languages become much more accessible. Learning a new language in a non-immersive environment will give you concepts, syntax, rules, and trivia, but you will not achieve fluency, which in programming languages gives you the power to craft original solutions to arbitrary problems.
Non-immsersive learning is great, but it’s only a stepping stone to fluency. Codecademy and Treehouse are great examples of non-immersive learning environments for JavaScript. Code Academy and Dev Bootcamp are great examples of immersive environments that lead people to fluency in Rails. That said, both of these immersive programs are too short a time to achieve fluency for people who are completely new to programming.
Remarkably, though, I’ve seen graduates of both programs creating immersive environments for themselves in Chicago. I’ve seen small groups of Code Academy students join up to continue coding together on a regular/continual basis. I’ve seen people literally eat/breathe Ruby on Tuesdays, when you can participate in Code & Coffee (at Starbucks, free wifi) from 7am-9am, then Geekfest (free lunch, open to public) from 12pm-1pm, then Chicago Ruby (free dinner, open to public) in the evening. I’ve seen people diligently stay immersed over the course of months and then transition into various apprenticeship programs around the city, which eventually lead to full-time employment opportunities.
A great example of this transition is Jean Bahnik. Jean is a marketing executive turned Trunk Club apprentice, who also happens to be fluent in French.
By: on: 2012-05-17 01:11:36 at: http://nuts.redsquirrel.com/post/23200685522
Tuesday May 15, 2012
Waxing Lyrical on Pathfinding
I’ve been attending and giving talks at the Software Craftmanship conference at Bletchley Park for a couple of years now. I’ve always found the crowd there engaging and great to hang out with, and I’d encourage you to come along if you’re not doing much on June 14th. There are still a few tickets left if you’re quick.
My talk proposal: Pathfinding Peril
This year my talk proposal is about pathfinding, a subject rather close to my heart since I started building a game. Finding the shortest path through a connected graph is a complex problem, and one which has a number of very useful applications, not just in the game sector.
Thankfully there are some efficient algorithms out there which solve it well. The aim of my session will be to teach the popular A-Star pathfinding algorithm, along with the factors to consider when choosing appropriate algorithm weights to make the implementation efficient.
A-star can be written in any language, but a simple (untested, probably buggy) version might look like this:
def find(goal)
closed_set = []
open_set = [ start_node ]
came_from = {}
while(!open_set.empty)
current = open_set.sort{|node| node.estimated_score }.first
return reconstruct_path(came_from, goal) if (current == goal)
open_set -= [current]
closed_set += [current]
current.neighbours.each do |neighbour|
next if closed_set.include?(neighbour)
possible_score = best_score[current] + current.cost_to(neighbour)
if !open_set.include?(neighbour) || possible_score < node.running_score
open_set += [neighbour]
came_from[neighbour] = current
neighbour.running_score = possible_score
neighbour.estimated_score = neighbour.running_score + neighbour.cost_to(goal)
end
end
end
return 'failed'
end
The session will last a couple of hours. I’ll take you through the basic A-Star implementation in the first 30 minutes of the session, and we’ll spend some time getting that coded up in the second 30 minutes. After a break, we’ll be running a tournament for an hour using Matt Wynne’s Robot Tournament engine. Your robot will be one of two characters in a maze, and the idea is to find the exit as soon as possible without being eaten by the minotaur that roams randomly around it.
You’ll get points for exiting the maze within a certain timeframe, exiting first, and simply avoiding being eaten! If I get time, I’ll write a basic ruby gem which allows you to parse the maze presented on stdin into nodes with connections.
We’ll run around 20 minute iterations, but probably reset the score every time so that the final score is the one that matters. It should be lots of fun!
What do you think of the session idea? How could I improve it?
By: on: 2012-05-15 15:02:40 at: http://feedproxy.google.com/~r/ChrisParsons/~3/lchfoJSrTLg/waxing-lyrical-on-pathfinding
Deliberate Practice
“Education comes from within; you get it by struggle and effort and thought.”
— Napoleon Hill
— Napoleon Hill
We all know the feeling of flow while coding. It's that moment when you hit a consistent stride and leave the surrounding world. It becomes effortless to glide over problems in an autopilot state and obstacles shrink from the size of mountains to the size of pebbles. Of course, being able to hit this flow means that you have practiced the problems you're facing to the point where it's of second nature. But, how did you get here? You practiced in two ways. First, you practiced moving forward to a place outside of your boundaries. Second, you also practiced the skills acquired from this action. Typically, practice is associated with the latter, but what is missing from this view of practice is the need to feel uncomfortable again. For me, when I begin to see problems as pebbles, it becomes time to deliberately seek a new mountain to climb. Both the acquisition and the polish of skills are important, but I want to shed some light on the practice of pushing boundaries, better known as deliberate practice.
As programmers there are many ways to do this. Here are a few that I find the most helpful.
Impose Artificial Constraints
In order to challenge myself I like to constrain the way I write solutions to problems. I once attended a code retreat where we were not allowed to use if or case statements in writing Conway's Game Of Life. This constraint forced a movement from a comfortable solution to one that left my pair and I feeling uncomfortable with the proceedings. We were forced to think in new ways that expanded our ideas of what constituted a solution. The solution we eventually came up with was a challenge to write.
When the event was over I thought back on my experience and realized that not only did I challenge myself, but I had a lot of fun doing it! It's interesting to see the creatively that flows from constraints. Now, when I approach problems that would have forced me into a solution involving if statements, I can feel comfortable moving outside of that solution and benefit from the understanding my new perspective has brought.
Learn New Languages & Paradigms
Steve Kim has a great post about learning a new language yearly. I want to echo his sentiment as an important part of deliberate practice. When I begin to feel comfortable with a language I know it's time to pick up a new one. The first language I felt comfortable with was Java. While in school I was forced into taking my first jump to another language when, as a class, we dove head first into C++. It was extremely intimidating at first and I started to feel discouraged (I have to manage memory?!?). Thankfully, I didn't back down and when I got the hang of it I was able to write some fun code for an embedded project. If I had stayed inside of my Java comfort zone I would have surely missed the chance to work on the embedded project.
The next big jump for me was to Clojure. This endeavor was another tough challenge because it introduced new paradigms. After some time and many struggles it started to click. Now, Clojure is one of my favorite languages to work with.
When you're feeling comfortable in a language pick up a new one. If you're a Java programmer, like I was, try out C++. If you're a Ruby programmer try out Python. When you feel comfortable in a certain paradigm switch to a new family of languages. There are many paradigms to explore including:
Switch Domains
The development community has many subcommunities such as web developers, front end developers, embedded developers, game developers, and so forth. One way to deliberately practice my craft is to extend myself into other communities. There are new ideas to be shared in the areas of design patterns, system structure, and much more when developers begin to blur the lines between each of these subcommunities. As I said earlier I took on an embedded project. While it was hard at first, the practice of the embedded design craft is important to the learning process and the movement towards greatness. I encourage everyone to take a look at the opportunities to deliberately practice in new domains.
Challenge Yourself
Practice is a process which will ultimately move your skills into a better state. Part of treating software as a craft is to continually raise the bar and engage the surrounding community to raise the bar. When programming begins to feel a little bit mundane seek out an exciting new mountain to climb. I challenge everyone to take a portion of practice time to deliberately practice.
By: patrick gombert on: 2012-05-15 00:00:00 at: http://8thlight.github.com/patrick-gombert/2012/05/15/deliberate-practice.html
NO DB
In the United States, in 1920, the manufacture, sale, and importation of alcoholic beverages was prohibited by a constitutional amendment. That amendment was repealed thirteen years later. During that period of prohibition, the beer industry died.
In 1933, when prohibition was lifted, a few giant grain companies started brewing beer. They completely cornered the market. And for nearly 50 years, we in the United State drank this fizzy bodily effluent and called it “beer”. The only way to tolerate the flavor was to drink it very cold.
As a teenager in the ‘60s, I never understood the attraction. Why beer? It was a pale, yellow, distasteful fluid derived from the urine of sick boars, and had no redeeming qualities that I could see.
In 1984, I went to England; and the scales dropped from my eyes. At last I understood. I had tasted beer for the first time; and I found it to be good.
Since those days the beer situation in the United States has improved dramatically. New beer companies are springing up all over the country; and in many cases the beer they make is actually quite good. We don’t have anything quite so nice as a good english bitter; but we’re getting close.
In the ‘80s a few giant database companies cornered the market. They did this by promulgating fear, uncertainty, and doubt amongst managers and marketing people. The word “relational” became synonymous with “good”; and any other kind of data storage mechanism was prohibited.
I was the lead developer in a startup in those days. Our product measured the quality of T1 communications lines. Our data model was relatively simple, and we kept the data in flat files. It worked fine.
But our marketing guy kept on telling us that we had to have a relational database. He said that customers would demand it. I found that to be a strange claim since we hadn’t sold even one system at that time, and no customer had ever mentioned our data storage technology. But the marketing guy was adamant. We just had to have a relational database. Flat files were prohibited.
As the lead developer, responsible for the quality of the software, my view of a relational database was that it would be a big, stogy, slow, expensive pain in the rear. We didn’t have complex queries. We didn’t need massive reporting capabilities. We certainly didn’t need a process with a multi-megabyte footprint sitting in memory and burning cycles. (Remember, this was the ‘80s). So I fought against this idea with everything I had; because it was the wrong technical solution.
This was not a politically astute move for me. Over a period of several months, a hardware engineer who managed to write a few lines of code, was moved into the software group. He was gradually given more and more responsibility, and was eventually named my co-manager. He and I would “share” the responsibility for leading the software team.
Uh huh. Sure. Right. A hardware guy with no real software experience was going to “help” me lead the team. And what do you think his first issue was? Why it was to get a relational database into our system!
I left a month later and started my consulting career. It was best career move I have ever made. The company I left no longer exists. I don’t think they ever made a dime.
I watched the relational database market grow during the ‘90s. I watched as all other data storage technologies, like the object databases, and the B-tree databases dwindled and died; like the beer companies in the 20s. By the end of the ‘90s, only the giants were left.
Those giants were marketing up a storm. They were gods. They were rulers. During the dot com bubble, one of them actually had the audacity to buy television ads that claimed that their product was “the power that drove the internet”. That reminded me of a beer slogan from the ‘70s “Ya gotta grab for all the gusto in life ya can.” Oh brother.
During this time I watched in horror as team after team put the database at the center of their system. They had been convinced by the endless marketing hype that the data model was the most important aspect of the architecture, and that the database was the heart and soul of the design.
I witnessed the rise of a new job function. The DBA! Mere programmers could not be entrusted with the data — so the marketing hype told us. The data is too precious, too fragile, too easily corrupted by those undisciplined louts. We need special people to manage the data. People trained by the database companies. People who would safeguard and promulgate the giant database companies’ marketing message: that the database belongs in the center. The center of the system, the enterprise, the world, the very universe. MUAHAHAHAHAHAHA!
I watched as SQL slipped through every crack and crevice in the system. I ran screaming from systems in which SQL had leaked into the UI. I railed endlessly against the practice of moving all business rules into stored procedures. I quailed and quaked and ranted and raved as I read through entire mail-merge programs written in SQL.
I hammered and hammered as I saw tables and rows permeating the source code of system after system. I hammered out danger. I hammered out a warning. I hammered out that the schema had become “The Blob”, consuming everything in sight. But I knew all my hammering was just slinging pebbles at a behemoth.
And then, in the first decade of the 21st century, the prohibition was lifted, and the NOSQL movement was born. I considered it a kind of miracle, a light shining forth in the wilderness. Finally, someone realized that there might just be some systems in the world that did not require a big, fat, horky, slow, expensive, bodily effluent, memory hog of a relational database!
I watched in glee as I saw BigTable, Mongo, CouchDB, and all the other cute little data storage systems begin to spring up; like little micro-breweries in the ‘80s. The beer was back! And it was starting to taste good.
But then I noticed something. Some of the systems using these nice, simple, tasty, non-relational databases were being designed around those databases. The database, wrapped in shiny new frameworks, was still sitting at the center of the design! That poisonous old relational marketing hype was still echoing through the minds of the designers. They were still making the fatal mistake.
“Stop!” I yelled. “ Stop! You don’t understand. You don’t understand.” But the momentum was too great. An enormous wave of frameworks rose up and smashed down on our industry, washing over the land. Those frameworks wrapped up the databases and fought to grab and hold the center of our applications. They claimed to master and tame the databases. They even claimed to be able to turn a relational database into a NoSQL database. And the frameworks cried out with a great voice heard all over the land: “Depend on me, and I’ll set you free!”
The name of this article is “No DB”. Perhaps after that rant you are getting an inkling of why I named it that.
The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.
It makes me crazy when I hear a software developer describe his system as a “Tomcat system using Spring and Hibernate using Oracle”. The very wording puts the frameworks and the database at the center.
What do you think the architecture of that system would look like? Do you think you’d find the use cases at the center of the design? Or would you find the source code arranged to fit nicely into the pattern of the frameworks? Would you find business objects that looked suspiciously like database rows? Would the schema and the frameworks pollute everything?
Here’s what an application should look like. The use cases should be the highest level and most visible architectural entities. The use cases are at the center. Always! Databases and frameworks are details! You don’t have to decide upon them up front. You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.
What is the best time to determine your data model? When you know what the data entities are, how they are related, and how they are used. When do you know that? When you’ve gotten all the use cases and business rules written and tested. By that time you will have identified all the queries, all the relationships, all the data elements, and you’ll be able to construct a data model that fits nicely into a database.
Does this change if you are using a NoSql database? Of course not! You still focus on getting the use cases working and tested before you even think about the database; no matter what kind of database it ends up being.
If you get the database involved early, then it will warp your design. It’ll fight to gain control of the center, and once there it will hold onto the center like a scruffy terrier. You have to work hard to keep the database out of the center of your systems. You have to continuously say “No” to the temptation to get the database working early.
We are heading into an interesting time. A time when the prohibition against different data storage mechanisms has been lifted, and we are free to experiment with many novel new approaches. But as we play with our CouchDBs and our Mongos and BigTables, remember this: The database is just a detail that you don’t need to figure out right away.
By: uncle bob on: 2012-05-15 00:00:00 at: http://8thlight.github.com/uncle-bob/2012/05/15/NODB.html
Monday May 14, 2012
Criticism
The title of this blog is zdsbs and it's been far too long (if ever on this blog) that I spewed some bs philosophy. So here we go with some bs philosophy about bs philosophy.
- Why care about bs philosophy or half baked ideas? They're fun. They're interesting. They're exploratory.
- What's easy to do with them? Criticize them. It's so easy, they're full of holes by their definition.
- What's harder, but more enlightening? Attempting to understand / identify with / grok / pick out the interesting kernel the idea is getting at.
When someone is presenting an idea it's important to understand the context. If it's 1/2 baked or a little bs there still may be a great idea there and that idea or conversation can be completely sidetracked if the audience is overly critical.
In college, the star of the philosophy department lamented to me her utter frustration of peoples instinct for criticism. She felt more good ideas and great conversations were lost because people were unwilling to try to understand where someone was going with an argument before attempting to poke holes in it.
Criticism is very important, but it's important to attempt to criticize the meat of an argument. And, sometimes it's just fun to roll with an argument even if it's total bs just to see where you end up.
By: Zachary D. Shaw on: 2012-05-14 21:24:17 at: http://feedproxy.google.com/~r/blogspot/zdsbs/~3/dYsnY_12C5o/criticism.html
Thinking Backwards or Forwards
I've heard references to a new style for documenting requirements. Greg Young talks a little about it in his post on business requirements at CodeBetter.com
I think he is onto something, as it is usually fairly obvious that business customers can handle some pretty complicated procedures and process flows, so why do they struggle with a machine, or state, based approach? The difference I suspect is that they focus on the action and not the state. The specs he describes are centered around a state, lists an action and only then describe the behavior that results from said action; let's write it thusly:
State ->Action->Behavior.
I'd be willing to bet that the users are really thinking like this, "I want it to do X (Behavior) so I have to push the yellow button (Action) but it only works if the red light is on (State), or
Behavior<-Action<-State
The style of documenting has enough in common that they understand what is being asked for even if, to them, it is listed backwards. As an aside, another major difference is I've never had a business user ever want to have a meta-discussion on how they think, so we tend to have to take it into account when designing the requirement gathering process but that will have to wait for its own post.
By: Kelly on: 2012-05-14 19:25:35 at: http://feedproxy.google.com/~r/TheCodewrightsTale/~3/V5LktXbkQSY/thinking-backwards-or-forwards.html
Attempting validated learning with Sol Trader
If you'd like to purchase Sol Trader you can do so at soltrader.net.
Sol Trader has been out just about two weeks now. It’s been great fun to actually launch the product and gain real feedback from people.
I’ve sold about forty copies. It’s a start, and a really good one. Thank you to those of you who have already purchased the game, and for all the feedback and encouraging emails I’ve received. I’ve learnt a huge amount already and it’s really helped me guide the way ahead.
The big question is: what’s next? How do I go from these humble yet encouraging beginnings to turning this game into something truly wonderful?
Validated learning
I’ve read Eric Ries’ excellent book The Lean Startup recently. In it he introduces a concept called Validated learning and goes on to define learning as the one important progress metric of startups: much more important than ‘customer numbers’ or ‘features’. Rather than define startups purely by ‘profit’ or ‘growth figures’, how can we ensure that we’re learning about how our business as fast as possible?
For Sol Trader, there are two main things that I need to find out.
- How can I ensure that I’m creating a game that people want to play, want to come back to, and want to tell their friends about?
- How can I ensure a steady stream of new players for the game?
The Sol Trader Hypothesis board
In order to support this learning, I’ve created the Sol Trader hypothesis progress chart:
This is what I’m using to track my theories. A good week would be one where I’ve managed to prove or disprove a theory or two, rather than simply adding in more and more ‘stuff’.
Note the Kanban limits to work in progress. In order to get theories tested as fast as possible, it’s important to get them through the process as fast as possible.
You can view and interact with the board for yourself: it’s on Trello here. I’m determined to do as much of this learning in the open as possible. I’d love your input into the hypotheses that I’m testing: you can vote and comment on particular theories and tell me why you think they’re a true (or completely wrong). Any input you give here will have an effect on what I work on next, so if you want to influence the development, then get involved!
Freed from featuritis
I’ve really enjoyed freeing myself from the continual focus on “features features features”. Features by themselves mean nothing: they are actually a drag on your product, as you have to spend time and effort maintaining them. It’s only the value that your customers gain from them that’s important. Focusing on theories has meant that I’m always making progress, even if I’m simply learning what doesn’t work.
Hang on: where is creativity in all this?
There’s a delicate balance here between listening to your customers and leading them in the direction you think they should go. I’m not going to sacrifice design flair and narrative to satisfy the baying (buying?) masses. This will likely always be a little bit of a niche game: there is a limit to the number of people interested in the genre. I plan to ultimately build the game I want to play, as opposed to the selling of something rubbish to satisfy everyone. Where’s the fun in that?
The important thing is to learn about your customer base, within the context of your original vision. If you cannot build a product within those constraints, time to look for a new business. Luckily, one of the earliest things I learnt through mailing list signups and a couple of hacker news appearances is that there’s a fair amount of latent demand for the vision I’ve got for the game, which is what spurred me on to get the alpha out in the first place.
What do you think of learning in public like this, and what do you think of my development approach?
By: on: 2012-05-14 09:18:47 at: http://feedproxy.google.com/~r/ChrisParsons/~3/HhO3cMbwW-M/attempting-validated-learning-with-sol-trader
Questions and Developers
Have you ever had a question you wanted to ask, but didn't?
Have you ever asked a question then immediately regretted asking it?
Have you ever been asked a question that made you rethink the problem you were trying to solve?
Have you ever struggled along a problem, broke down, asked somebody, and got an immediate answer?
Questions have the power to expose problems, gather information, refine solutions, and save time. Questions can also waste time, make people feel stupid, and shift discussion to the wrong topic. Knowing what questions to ask can be the difference between an average developer and a great developer. Questions cause learning but can also be scary to ask. However, there are times when developers must be brave and ask difficult questions.
Questions Induce Learning
If you don't think critically and ask questions, you won't learn anything. Since learning is a huge part of a developer's job, questions need to be asked on a frequent basis. Three major types of questions asked by developers are about details, concepts, and opinions.
When adding code to a large codebase, it often saves time to ask another developer how the details of some code works. When a developer is asking a question about code, there is a good chance that there is some opportunity to refactor. Like a dog, code is usually only clean if you just got done cleaning it. So make sure to ask questions and refactor accordingly whenever possible.
There are too many concepts for one developer to know in the software industry, so they specialize. Since they can't specialize in everything, questions are a necessity. I have found that passionate developers will never be bothered by questions about their specialty. They love their field and they love sharing knowledge.
Another question you won't see a passionate developer turn down is one that is asked to investigate an opinion. The code in an application is a reflection of the developer's knowledge and opinions. Understanding these opinions is crucial to writing code that matches the rest of the application and forming your own opinions. It is important to understand the intent behind the code before you change it, even if the style is harmful or messy.
Questions Are Terrifying
Nothing gets the nerves firing more than asking a question when you are uncomfortable. When I was an apprentice asking questions was very intimidating at times. The major fear is that I would be exposed as being a complete n00b. That fear was pretty valid because I was a complete n00b. I eventually realized that asking good questions earned myself respect as a developer.
During a code retreat I got to pair with somebody new to developing software. Our pairing session was pretty ineffective because my pair was afraid to ask me questions. He knew conceptually how to solve the problem, but wasn't familiar with Ruby's syntax. When it was his turn to code, he could've walked me through his idea and then asked how to represent that in Ruby. Instead he would spend time writing code that was incorrect syntax and confusing.
In successful companies, employees help each other out for the greater good of the company. If you are in a work environment where questions are seen as an annoyance, get a new job. How can you expect to learn if you get the cold shoulder from a colleague every time you try to learn from him/her? If you get some resistance getting an answer out of somebody, calm them down and persist. Help them understand why it is important that you know something and ask again.
Asking Questions Isn't Always Easy
There are times when asking a question can be extremely difficult. Those are typically the times when it is critical that they are brought up. If you call software your craft, it is your responsibility to ask the difficult questions.
Playing the devil's advocate for somebody with strong opinions can be a very difficult job. Asking questions that go against somebody's beliefs can go wrong very easily. It is hard for the person being questioned to not feel attacked. In this type of situation framing is extremely important. Start off your questions with "I don't understand" or "I think I'm missing something." The person being questioned will likely be more explanatory rather than defensive.
Asking questions in an apathetic environment is also a difficult task. When nobody cares about the topic, it is hard to have a discussion about it. If this is an important topic, you must ask thought provoking or scary implication questions to get their attention. That might sound like a politician's strategy, but if the topic is truly important that is an extremely effective strategy.
Conclusion
Developers rely on asking questions effectively every day. Since questions are so important, developers should be consciously aware of the roles they play in their job. Questions cause learning, can be scary, and are difficult to ask at times. I hope that after reading this blog, you understand the importance of questions and know a little bit more about the role they play in a developers job.
By: dave moore on: 2012-05-14 00:00:00 at: http://8thlight.github.com/dave-moore/2012/05/14/questions-and-developers.html
Sunday May 13, 2012
Using System.Threading.Tasks On MonoTouch
I ran into an issue this week where I was attempting to load data from a web service asynchronously using System.Threading.Tasks on MonoTouch. I was able to fire the task off but kept getting an error trying to update UI elements when callback was fired.
After a little beating my head against a wall, I took a walk and grew a neuron and this is what I came up with to resolve the issue. Note the call to InvokeOnMainThread.
private IEnumerable<Product> GetProducts(Position position)
{
return productsService.GetProductsNear(position);
}
private void BeginGetProducts()
{
Activity.PushNetworkActive();
var scheduler = TaskScheduler.FromCurrentSynchronizationContext();
Task.Factory.StartNew(() => GetProducts(currentPosition))
.ContinueWith(OnProducts, scheduler);
}
private void OnProducts(Task<IEnumerable<Product>> task)
{
if(task.IsFaulted)
HandleException(productsTask.Exception);
else
{
InvokeOnMainThread(() => {
this.products = task.Result;
ShowProducts();
});
}
Activity.PopNetworkActive();
}
By: Bobby Johnson on: 2012-05-13 20:40:54 at: http://feedproxy.google.com/~r/IAmNotMyself/~3/TT-jP0oNxa4/
Declaring Pass or Fail - Handling Broken Assumptions
When using TDD, it's a good practice to declare - aloud or in your mind - whether the next test run will pass or fail (and in what way it will fail). Then when your assumption about the outcome happens to be wrong, you'll be surprised and you can start looking more closely at why on earth the code is not behaving as you thought it would.
I had one such situation in my Let's Code screencasts where I missed a mistake - I had written code that's not needed to pass any tests - and noticed it only five months later when analyzing the code with PIT mutation testing. You can see how that untested line of code was written in Let's Code Jumi #62 at 24:40, and how it was found in Let's Code Jumi #148 at 4:15 (the rest of the episode and the start of episode 149 goes into fixing it).
I would be curious to figure out a discipline which would help to avoid problems like that.
Here is what happened:
I was developing my little actors library. I already had a multi-threaded version of it working and now I was implementing a single-threaded version of it to make testing actors easier. I used contract tests to drive the implementation of the single-threaded version. Since the tests were originally written for the multi-threaded version, they required some tweaking to make them work for both implementations, with and without concurrency.
I was already so far that all but one contract test were passing, when I wrote the fateful line idle = false; and ran the tests - I had expected them to pass, but that one test was still failing. So then I investigated why the test did not pass and found out that I had not yet updated the test to work with the single-threaded implementation. After fixing the test, it started failing for another reason (a missing try-catch), so I implemented that - but I did not notice that the line I had added earlier did not contribute to passing the test. Only much later did I notice (thanks to PIT) that I was missing a test case to cover that one line.
So I've been thinking, how to avoid mistakes like this in the future? I don't yet have an answer.
Maybe some sort of mental checklist to use when I have written some production code but it doesn't make the test pass because of a bug in the test. Maybe if I would undo all changes to production code before fixing the test, would that avoid the problem? Maybe the IDE could help by highlighting suspicious code - the IDE could have two buttons for running tests, one where the assumption is that the tests will pass and another where they are expected to fail. Then when an assumption is broken, it would highlight all code that was written since the last time tests passed and/or assumptions were correct, which might help in inspecting the code.
Or maybe all problems like this can be found automatically with mutation testing and I won't need a special procedure to avoid introducing them?
UPDATE: In a following blog post I'm experimenting a better way of doing this refactoring.
By: Esko Luontola on: 2012-05-13 09:33:10 at: http://blog.orfjackal.net/2012/05/declaring-pass-or-fail-handling-broken.html
Passing Contract Tests While Refactoring Them
In my last blog post I explained how I at one time created a new implementation to pass the same contract tests as another implementation, but due to having to refactor the tests at the same time (the two implementations have a different concurrency model, so the contract tests must be decoupled from it), I missed a problem (wrote some dead code). Since then I've retried that refactoring/implementation using a different approach, as I explained in the comments of that blog post.
One option would have been to refactor the whole contract test class before starting to implement it, but that goes against my principles of doing changes in small steps and having fast feedback loops. So the approach I tried is as follows:
- Extract a contract test from the old implementation's tests by extracting factory methods for the SUT, creating the abstract base test class and moving the old implementation's test methods there.
- Create a second concrete test class which extends the contract tests, but override all test methods from the contract test and mark them ignored. This avoids getting lots of failing tests appearing at once. Maybe mark each of the overridden versions with a "TODO: refactor tests" so as to not forget the next step.
- Inspect the contract test method which you plan to implement next and see if it requires some refactoring before it would work for both implementations. Refactor the test if necessary. This gives a systematic way for updating the contract tests in small tests and avoids refactoring while tests are red.
- Unignore one contract test method and implement the feature in the new implementation. This lets you focus on passing just one test at a time, as is normal in TDD.
I recorded my experiment of using this strategy as a screencast:
By: Esko Luontola on: 2012-05-13 09:29:56 at: http://blog.orfjackal.net/2012/05/passing-contract-tests-while.html
Saturday May 12, 2012
Learn a New Language
We're already a quarter into the year. Have you learned a
new language yet?
In Pragmatic Programmer, one of the 70 tips is to invest regularly in your knowledge portfolio. And probably one of the most popular advice is to learn at least one new language every year. So, what language have you learned this year? If you haven't started, don't worry, there's still some time. Here are some tips to get you started.
-
Picking Your Language
Some of you have a personal list of languages you want to learn. Here's my personal list of languages (in alphabetical order):
- Amber
- BiwaScheme
- Clojure
- Dart
- Elixir
- Go
- Mirah
- Objective-C
- OCaml
- Rust
- Self
-
Koans
If the language you want to learn has a set of koans, then I highly recommend going through them. Koans are sets of unit tests that exercise the features of the language. The idea, originally by Ara Howard, became popularized when EdgeCase introduced Ruby Koans. From there on out, others have created koans for other languages.
Here is a list of some of them:
If no one wrote koans for the language you want to learn, what better way to learn a language than by creating koans? Not only will it be a motivation to learn a language, you will also be contributing to the community by giving others the opportunity to learn the language.
-
Building A Breakable Toy
As described in Apprenticeship Patterns, a breakable toy is a pet project that allows you to learn in a safe environment where you're allowed to make mistakes and fail. Experience builds upon failure and success.
If you prefer to write something other than koans, build a breakable toy. One example would be to write a Tic-Tac-Toe that has an unbeatable computer. Another would be to build a simple HTTP client. Try not to use third-party libraries and instead rely on the standard library that is provided in the language. Push it out to GitHub and let the community see your project.
-
Contributing to Open Source Project
Find an open source project that interests you in the language you want to learn. This gives you an opportunity to read someone else's code, looking at the style and convention. You may also pick up on language patterns that other developers use.
Be careful when choosing a popular project. Popular != quality and may fall short of good practices, patterns, and principles.
-
Pair Programming
Pair with someone who has a deep understanding of the language you want to learn. You can quickly pick up on the idioms and conventions. This may be the quickest way to dive into a new language and it is to your advantage to ask many questions.
I've probably stated the obvious, but hopefully this will kickstart your getting started on learning a new language. As pragmatic programmers, as craftsmen, it's important to keep up to date with current technologies, languages, and environments. Invest in your knowledge portfolio!
Oh, if you haven't already, check out Jason Rudolph's blog post for more inspiration and motivation.
By: steve kim on: 2012-05-12 00:00:00 at: http://8thlight.github.com/steve-kim/2012/05/12/learn-a-new-language.html
Wednesday May 09, 2012
Guest post: Planning Poker – The Power of Two
About the Author: Chris Fortuin is a project manager and loves to deliver awesome software to his customers through team collaboration. During the first decade of his professional life he learned his project management and people skills as a management consultant for Ernst & Young in The Netherlands. Subsequently, a long aspired life-change brought him with his family to Australia where he continued delivering software solutions in large and complex organisations.
Throughout his career Agile was, and remains, his passion. It started more than ten years ago in Europe with DSDM and continues nowadays with great challenges of making Agile work with his customers using Scrum and XP practices. By providing industry presentations and customised training courses he is privileged to share his knowledge and experience in topics like project management, Agile software development and Earned Value Management. Last but not least, his favourite hobby is to participate in triathlons and what better place to do this than in sub-tropical Queensland.
Chris’ website for my Agile work: http://orangefortune.com/agile.html
Throughout his career Agile was, and remains, his passion. It started more than ten years ago in Europe with DSDM and continues nowadays with great challenges of making Agile work with his customers using Scrum and XP practices. By providing industry presentations and customised training courses he is privileged to share his knowledge and experience in topics like project management, Agile software development and Earned Value Management. Last but not least, his favourite hobby is to participate in triathlons and what better place to do this than in sub-tropical Queensland.
Chris’ website for my Agile work: http://orangefortune.com/agile.html
To plan an Agile project most teams play Planning Poker to estimate the size of user stories. Tools are available like a deck of cards, paper or nowadays even Apple/Android apps. Simplicity is one of our Agile principles and The Power of Two practice allows you to play Planning Poker without any need for these tools but just using one hand. I’ll share with you the basics and throw in some adaptations that happened when I used The Power of Two with my teams.
The Basics
The basics for The Power of Two are straightforward and all you need are team members with five fingers on one hand. The number of points for the size of a user story represent the number of fingers shown by a team member using the following sequence with each successor doubling in size:
- No fingers by showing your fist => 0 points
- One finger => 1 points
- Two fingers => 2 points
- Three fingers => 4 points
- Four fingers => 8 points
- Five fingers or full hand (two to the power of five) – off the charts!
- Flat hand – pass
Finally, except for showing estimates by using number of fingers according to this sequence, the Power of Two just complies with the rules for playing Planning Poker.
The Power of Two really stands out for me because of it’s proven simplicity in multiple ways:
- The use of only one hand for showing estimates which makes it fast and easy;
- The estimates covering a wider range (1-8) than the same Fibonacci sequence (1-5) which creates clearer separation of estimates;
- The team soon taking over control from the facilitator for when a new estimate is due. Actually it feels like the team gets in a mode simular to when you’re playing Rock-Paper-Scissors (RPS);
- The flexibility to play Planning Poker anywhere, anytime with anyone because you don’t require any tools.
When playing Planning Poker using The Power of Two at least consider the following lessons learned:
- When playing The Power of Two for the first time with a team write down the sequence on a whiteboard for easy reference and to avoid mistakes;
- Initially relate one story point as one ideal developer day because this conveniently translates to user story sizes that fit within one iteration;
- At least try the Power of Two sequence, instead of the Fibonacci, because I never had the need, or a request from a team member, to convert back to a Fibonacci sequence.
Adaptations
I have used the Power of Two with my teams by always starting with the basics as just described. During Planning Poker I have often noticed the following adaptations from by my team members:
- Using half an index finger to indicate a small story of 0.5 point;
- Taking the average for the higher end estimates as consensus. For example if we only have estimates of 4 and 8 points remaining, go for 6 points and avoid wasting time;
- Set aside the larger user stories initially (five fingers or full hand) because they normally won’t fit in one iteration. They need to be decomposed and re-estimated or re-estimated as an epic using a higher sequence of points that’s consistent with the lower sequence. For example a higher sequence with 20 points for a user story is still ten times as big as the 2 points from the lower sequence. And don’t forget: for the higher sequence the Power of Two can be used again (for example: 10-20-40-80)!
Finally, enjoy using The Power of Two when playing Planning Poker and let us know your experiences!
For information about Planning Poker: http://en.wikipedia.org/wiki/Planning_poker
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: scrumology on: 2012-05-09 20:01:00 at: http://feedproxy.google.com/~r/Scrumology/~3/1QQrx2m8yBw/
Some statistical evidence for benefits of Agile principles & practices
I’ve just published a statistical report which I think provides strong evidence for the benefits of Agile (and all its friends). The full article and report is available here:
http://blogs.7digital.com/dev/2012/05/09/development-team-productivity-at-7digital/
By: Rob on: 2012-05-09 12:39:33 at: http://feedproxy.google.com/~r/robbowley/~3/Vy0QB0C0Cdg/
Tuesday May 08, 2012
Advice for Novice Mentors
In the past year I've started to shift into mentoring more, both at 8th Light and outside of 8th Light. Despite having been a craftsman for three years and having been an apprentice with a great mentor myself, I was woefully unprepared to teach others. Hopefully this blog can serve as advice to help novice mentors with their first apprentices. This article is an overview of the topic, and so presents a large array of ideas in general rather than focusing on any particular issue in depth.
My journey into mentoring started by teaching my friends who were interested in programming. I've also been a mentor at Code Academy for its first three semesters. Some of the knowledge in this blog can be applied to any sort of apprenticeship, while some of it may be specific to a "once a week" sort of mentor/student relationship as found in Code Academy.
The Role of a Mentor
My original image of what a mentor should be was very narrow. I thought that a mentor was there to teach the student everything they needed to know. I've since come to realize that an effective mentor/student relationship occurs when the student is responsible for their own learning, and the mentor acts as a guide along that path. The mentor is still there to help the student learn, but in addition to teaching and pairing with the student, other duties include suggesting books to read, introducing the student to people they should meet, and answering questions.
For example, in meeting with my Code Academy students, there's been a couple weeks where we weren't able to meet, due to one of us being sick or just other stuff coming up, but I was still able to answer questions through email and offer them advice. Looking back on it, I was still able to help them, just not through pairing.
Even thinking back to when I was an apprentice, I can recall a number of occasions where spending just five minutes talking to my mentor saved me hours of work.
Mentoring is Hard
Another mistake that I made was underestimating how hard it is to be a good mentor. I was definitely tricked into thinking it was easy with my first student, Cyrus. As a graduate student eventually pursing his Ph.D., he was the type of person who already knew how to learn and was eager to do so. Cyrus would have picked up programming with or without my help. Some of the other people I've had the pleasure to mentor have required a different level of guidance.
In fact, hands-on versus hands-off has been one of my biggest struggles with mentoring. Since I am a self-admitted keyboard hog, I tend to overcorrect to the side of not enough involvement. On one hand, too much involvement means that they don't get a chance to try out things for themselves. On the other hand, too little involvement means that they might spend more time than they should have struggling through their problems and aren't benefiting from your experience. Finding an appropriate balance has been a challenge, but what has helped me is more communication between myself and the student.
One Size Doesn't Fit All
That said, if you find a good balance or technique with one student, that doesn't necessarily work for every person you teach. Some students may need more assistance or different styles of teaching than others.
The most obvious difference would be students starting with two different skill levels. However, even with two students of similar skill level, they may have completely different goals or ways of thinking. A great example of this is the overall apprenticeship program at 8th Light. We've had apprenticeships lasting from as short as two months to as long as seven or eight months.
Find a Good Student
Given that a student is responsible for his own learning, finding a good student is by far the most important part in being an effective mentor. A good student has two main qualities: a passion for learning, and an ability to learn. Like my friend Cyrus, if a person has a passion for learning, they won't need too much from you.
Some prior experience with programming may be a plus, but depending on the situation, it isn't necessarily a requirement for a good student.
Get to Know the Student
After you've found a good student, the first step is to just talk to the student. Ask them about their background. Ask what they already know. Ask what they hope to learn. Even something as simple as how they prefer to learn can be useful. Most importantly, ask what they expect from you.
After that, find a way to figure out where their skill level is at beyond just talking to them. Hint: The answer is probably just pairing.
I made this mistake when I first started mentoring one of my students. We misgauged his starting skill level and had a month where it felt like we made little progress. Once we talked it over, we decided to go back to square one and had a much more successful time continuing. If we had just spent a bit more time at the beginning, I'm sure the first month of the mentoring would have far more effective. This mistake was not due to either the student or myself alone, but was more indicative of a lack of communication between us.
Have Focus
Once you have gotten to know your student, the next step is to figure out what to do during your meetings. For my Code Academy students, I've only been meeting once a week for about an hour, so before we meet, I make sure to spend some time thinking about what we could discuss.
The best case scenario is when the student comes to you with something to work on. Also, this doesn't mean you can't just pair on random code for the meeting, but you don't want to spend half your time trying to figure out what to work on.
Be Prepared
Continuing the previous thought, if you are going to present yourself as an authority on a subject, you should spend some time brushing up and reviewing it. A little preparation goes a long way.
Examples of some things I might do to prepare range from reviewing one of the SOLID principles complete with examples all the way to making sure my system is set up with whatever code we want to pair on. If you are unprepared for the meeting, it's a waste of both your time and theirs.
Be Consistent
Going along with preparation, consistency is also key. Try to schedule a regular meeting with your student. I know that one of the big hurdles I faced with my first Code Academy student was finding a time to meet each week. I was able to be a much better resource for my second Code Academy student as compared to my first. Part of that was due to having more practice at teaching, but part of it was meeting more consistently and for longer periods.
Learn About Learning
One thing I've done recently is start to read about different learning models. Putting names and stages to a person's level of knowledge can be useful for knowing when to elaborate on a subject or move on and let them internalize it on their own. I've only just started doing this, but have seen a couple small places where it's improved my teaching.
Also, use a variety of different teaching methods. Draw pictures on a whiteboard, ask leading questions, give them coding assignments or even give them reading assignments. Different people prefer different ways of learning, so this helps find the methods that work for them.
Have Fun
Most importantly, you need to have fun. Hopefully both you and your student look forward to your meetings. One thing that I've seen work as both a fun and useful exercise is to have your student take ownership of a slightly larger application that takes multiple iterations to complete. Not only is building something to completion fun, but this gives you something easy to choose to work on and forces the student to deal with code he wrote.
The exact application would depend on the student in question and the technologies he focused on learning, but many of 8th Light's internal applications have been started as apprentice projects.
Closing Notes
Hopefully this helps you to not make some of the same mistakes as I have when you start to teach others. That said, I'm still a novice when it comes to teaching, so I still have a lot to learn myself.
Like with coding, look to people who are good at mentoring for examples on how to effectively teach. Mentoring is an art, and there are a lot of people who are already very skilled at it. Also, if you have a different style of teaching that works for you, then go ahead and use it. Even at 8th Light we have a wide array of mentors with a variety of teaching styles, all of which have contributed to the knowledge of past and present apprentices.
By: eric meyer on: 2012-05-08 00:00:00 at: http://8thlight.github.com/eric-meyer/2012/05/08/advice-for-new-mentors.html
Sunday May 06, 2012
Quick Tip: Firing Up Rubinius to Dig into Ruby Source
The other day I came across another great use-case for Rubinius that might be useful for a lot of developers.
I use pry as my ruby REPL regularly. Often I feel the need to dig deeper into some part of the ruby stdlib. For example, just this week I wanted to find out what String.replace() does. Reading the documentation I still felt the need to dig deeper and see what’s going on.
Using CRuby (the ruby version you’re probably using) one can see the source code in pry by installing the proper gem (gem install pry-doc). Here’s the source code we got:
1 2 3 4 5 6 7 8 9 10 11 12 | |
As you can see there isn’t a lot we can understand about the internal behavior of this function without digging deeper into str_replace, which isn’t really possible from pry.
Enter Rubinius
After you install rubinius (rvm install rbx --1.9) and switch to it (rvm use rbx) you can get a more interesting result (you might have to gem install pry after switching to rubinius for the first time):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | |
Now, not only can we see that String#replace replaces the contents of the String object we have with the contents of the other one (basically, treating String as a pointer and changing what it points to), we are free to dig deeper with the joys of ruby. For example, if we want to understand what StringValue does we’re just a short show-source StringValue away from it!
This simple ability is a valuable resource in getting intimate with ruby as a primary language. If you find more cool uses of this, please let me know.
You should subscribe or follow me on twitter!
By: on: 2012-05-06 19:51:00 at: http://feedproxy.google.com/~r/TheCodeDump/~3/aJR3BooMlRo/
Wednesday May 02, 2012
Sol Trader now in Alpha
It’s released!
After a hectic four months of early development Sol Trader has gone into Alpha.
With this release, you can explore the known Solar System and make money through trading on the stock markets. There isn’t much else there yet, but I’m planning a slew of improvements over the coming months.
I’ve decided to charge right off the bat: you can buy the Alpha for £5 (about $8). This price will go up as I put more work into the game, and future game updates will be free until it’s finished.
Exciting yet terrifying
This is both a wonderfully exciting and deeply terrifying moment for me. The game isn’t near finished, yet I’ve released it on an unsuspecting set of game players. I’ve been reading the Lean Startup and I think it’s ready for feedback. This is my Minimum Viable Product.
The exciting bit: I finally get a sense of whether I’m going in the right direction and whether people might enjoy the fairly simple mechanics that are on offer in this version. Seeing Paypal emails letting me know that people have bought the game is very gratifying, even if I have to manually activate every purchase with a knocked-together ruby script.
The terrifying bit is: I finally get a sense of whether people actually might play this game. After all, if nobody likes it at all, there’s not much point continuing.
How I’m going to improve the game
I’m using KISSMetrics to track both website activity and gameplay. So far it’s working out well: I can see how people go through the site, make purchases, and then sign in and play the game.
I’ve deliberately not worked on the code behind the game for a couple of days, to let the metrics filter through and inform me about what’s next. So far the reaction has been generally positive - my metrics have had good framerates and people are playing for an average of 15 minutes and making about a dozen visits to planets each.
My first impressions based on early metrics and feedback: I need to make the economy more realistic as I think this will cause people to play the game for longer, and I need to add a video of gameplay to the front page to improve my sign up/purchase rates.
More on how I’m following the Lean Startup approach over the next few weeks and months.
The long road
This is where I need self-discipline more than ever. My weakness is that when I feel like I’ve achieved something (like launching an alpha), my tendency is straight away to look for the next thing. I’m determined not to let that happen here. I feel like I’ve delivered on perhaps 5% of the vision for the game. I’m passionate about seeing the rest of the vision fulfilled.
The more of you who buy the game now and play it, the clearer the way forward becomes. I’m grateful for every purchase: thank you to the brave early adopters!
If you’ve purchased the game, what can I do to improve it? If you haven’t purchased it yet, what can I put on the website to better inform your decision? Let me know.
By: on: 2012-05-02 14:37:44 at: http://feedproxy.google.com/~r/ChrisParsons/~3/QSciIzmuM_4/sol-trader-now-in-alpha
Tuesday May 01, 2012
Unit Test Focus Isolation
Good unit tests are FIRST. The I in FIRST stands for Isolation and is easily confused with the R, Repeatability. Ironically the I is itself not well isolated. I want to take a moment to focus on an often forgotten side of unit test isolation: test focus.
A good unit test focuses on testing just one thing and it doesn't overlap with other tests - it has high cohesion and low coupling. Conversely, if you change one rule in the production code, then only one unit test should fail. Together with well named tests this makes it easy to find the reason for a test failure (and giving tests meaningful names is easier when each of them focuses on just one thing).
I came up with a good example in Let's Code Jumi episode 200 (to be released around October 2012 - I have a big WIP ;). I'm showing here a refactored version of the code - originally the third test was all inline in one method and it might have been less obvious that what the problem was.
Example
The system under test is RunIdSequence, a factory for generating unique RunId instances. Here are the two unit tests which were written first:
@Test
public void starts_from_the_first_RunId() {
RunIdSequence sequence = new RunIdSequence();
RunId startingPoint = sequence.nextRunId();
assertThat(startingPoint, is(new RunId(RunId.FIRST_ID)));
}
@Test
public void each_subsequent_RunId_is_incremented_by_one() {
RunIdSequence sequence = new RunIdSequence();
RunId id0 = sequence.nextRunId();
RunId id1 = sequence.nextRunId();
RunId id2 = sequence.nextRunId();
assertThat(id1.toInt(), is(id0.toInt() + 1));
assertThat(id2.toInt(), is(id1.toInt() + 1));
}
These unit tests are well isolated. The first focuses on what is the first RunId in the sequence, the second focuses on what is the relative difference between subsequent RunIds. The second test is unaware of the absolute value of the first RunId, so the tests don't overlap. I can easily make just one of them fail and the other pass.
The RunIdSequence needs to be thread-safe, so here is the third test, with the relevant bits highlighted:
@Test
public void the_sequence_is_thread_safe() throws Exception {
final int ITERATIONS = 50;
List<RunId> expectedRunIds = generateRunIdsSequentially(ITERATIONS);
List<RunId> actualRunIds = generateRunIdsInParallel(ITERATIONS);
assertThat("generating RunIds in parallel should have produced the same values as sequentially",
actualRunIds, is(expectedRunIds));
}
private static List<RunId> generateRunIdsSequentially(int count) {
List<RunId> results = new ArrayList<RunId>();
// XXX: knows what is the first ID (RunId.FIRST_ID, even worse would be to use the constant 1)
// XXX: knows how subsequent IDs are generated (increase by 1)
for (int id = RunId.FIRST_ID; id < RunId.FIRST_ID + count; id++) {
results.add(new RunId(id));
}
return results;
}
private static List<RunId> generateRunIdsInParallel(int count) throws Exception {
final RunIdSequence sequence = new RunIdSequence();
ExecutorService executor = Executors.newFixedThreadPool(10);
List<Future<RunId>> futures = new ArrayList<Future<RunId>>();
for (int i = 0; i < count; i++) {
futures.add(executor.submit(new Callable<RunId>() {
@Override
public RunId call() throws Exception {
return sequence.nextRunId();
}
}));
}
List<RunId> results = new ArrayList<RunId>();
for (Future<RunId> future : futures) {
results.add(future.get(1000, TimeUnit.MILLISECONDS));
}
Collections.sort(results, new Comparator<RunId>() {
@Override
public int compare(RunId id1, RunId id2) {
return id1.toInt() - id2.toInt();
}
});
executor.shutdown();
return results;
}
This test is not isolated. It defines same things as those two other tests, so it has overlap with them: it knows what is the first RunId and how subsequent values are generated. If one of the two first tests fail, also this test will fail, even though this test is meant to focus on thread-safety just as its name says.
Here is an improved version of the same test, with changes highlighted:
@Test
public void the_sequence_is_thread_safe() throws Exception {
final int ITERATIONS = 50;
List<RunId> expectedRunIds = generateRunIdsSequentially(ITERATIONS);
List<RunId> actualRunIds = generateRunIdsInParallel(ITERATIONS);
assertThat("generating RunIds in parallel should have produced the same values as sequentially",
actualRunIds, is(expectedRunIds));
}
private static List<RunId> generateRunIdsSequentially(int count) {
RunIdSequence sequence = new RunIdSequence();
List<RunId> results = new ArrayList<RunId>();
for (int i = 0; i < count; i++) {
results.add(sequence.nextRunId());
}
return results;
}
private static List<RunId> generateRunIdsInParallel(int count) throws Exception {
final RunIdSequence sequence = new RunIdSequence();
ExecutorService executor = Executors.newFixedThreadPool(10);
List<Future<RunId>> futures = new ArrayList<Future<RunId>>();
for (int i = 0; i < count; i++) {
futures.add(executor.submit(new Callable<RunId>() {
@Override
public RunId call() throws Exception {
return sequence.nextRunId();
}
}));
}
List<RunId> results = new ArrayList<RunId>();
for (Future<RunId> future : futures) {
results.add(future.get(1000, TimeUnit.MILLISECONDS));
}
Collections.sort(results, new Comparator<RunId>() {
@Override
public int compare(RunId id1, RunId id2) {
return id1.toInt() - id2.toInt();
}
});
executor.shutdown();
return results;
}
Now it doesn't anymore know about those two design decisions. It's focused on just testing thread-safety and doesn't duplicate the other tests nor the production code. I can change the production code to make any one of the three tests to fail while the other two still pass.
Conclusion
When I try to write as isolated/focused tests as possible, it makes it easy to find the cause of a test failure. If I don't know why some code exists, I can comment it out and see which tests fail - their names will tell why the code was written. When removing features, I can remove whole tests which define that feature, instead of having to update non-cohesive tests. When changing features, I need to update only a few tests.
P.S. I've been thinking that it might be possible to measure automatically the "unitness" of tests using mutation testing tools such as PIT. The fewer tests per mutation fail, the better. And if a test always fails together with other tests, then it's a bad thing. It might help in pinpointing tests which need some refactoring.
By: Esko Luontola on: 2012-05-01 19:13:14 at: http://blog.orfjackal.net/2012/05/unit-test-focus-isolation.html
Choice of Words in Testing Frameworks (...and how many get it wrong, including RSpec)
One [word] to rule them all... and in the darkness bind them.
I want my testing framework to be able to express the ideas that I have in my mind in the best possible way. This includes giving the tests the best possible names. Unfortunately, lots of testing frameworks force the developer to start or end his test names with predefined words - such as "define", "it", "should", "given", "when", "then". This can be harmful, because they incline the user to write his test names always following the same structure, even in situations where that way of structuring tests is suboptimal.
Predefined words produce twisted sentences
Here are some trivial counterexamples of specification-style test names, to prove that requiring the test to start with a predefined word will sometimes lower the quality of the test names. Here is a specification of Fibonacci numbers which is taken straight from their Wikipedia article:
Fibonacci numbers:
- The first two Fibonacci numbers are 0 and 1
- Each remaining number is the sum of the previous two
RSpec requires the test fixtures to start with the word "define" and the tests with "it", in addition to which RSpec's documentation encourages the tests to start with "it should". Let's try to twist the above specification of Fibonacci numbers into that style. Here is my best attempt which still holds the same information:
Define Fibonacci numbers:
- it should have the first two numbers be 0 and 1
- it should have each remaining number be the sum of the previous two
Urgh. Totally unnatural way of saying the same information. Lots of unnecessary words need to be added to make the test names full sentences.
If we use example-style, then it's possible to write the test names, but valuable information is lost:
Define Fibonacci numbers:
- it should calculate the first two numbers
- it should calculate each remaining number
The problem appears to be that "it" is forced to be the subject of the sentence. We can get around that restriction by adding more "define" elements, but then the tests become awfully verbose without adding any new information:
Define Fibonacci numbers:
- Define the first number:
- it should be 0
- Define the second number:
- it should be 1
- Define each remaining number:
- it should be the sum of the previous two
Here is another example, written in a slightly different style:
Stack:
- An empty stack
- is empty
- After a push, the stack is no longer empty
- When objects have been pushed onto a stack
- the object pushed last is popped first
- the object pushed first is popped last
- After popping all objects, the stack is empty
And the same using RSpec's predefined words:
Define stack:
- Define an empty stack
- it should be empty
- it should, after a push, be no longer empty
- Define a stack onto which objects have been pushed
- it should pop first the object pushed last
- it should pop last the object pushed first
- it should, after popping all objects, be empty
It was necessary to change the order of some of the sentences for them to make sense, and it was not natural to write the "it should, after..." tests - their sentence order should have been changed to make them more natural, but then the effect would have been before the cause, which is neither good. Also the subject of some sentences had to be changed from "the object pushed last" to "it" (i.e. stack) and the subject of the old sentence became the object of the new sentence.
The testing framework should obey the developer, not the other way around! The developer is the one knows best that how to make a sentence convey his intent. A testing framework, which forces the developer to use a predefined style of writing his sentences, is immoral!
Predefined words do not improve the test names
What about example-style test names? Predefined words are equally bad for them. Here are Uncle Bob's Bowling Game Kata's test names in RSpec format:
Define bowling game:
- it should score gutter game
- it should score all ones
- it should score one spare
- it should score one strike
- it should score perfect game
Adding "it should" does not improve the test names. They don't make the intent any clearer. It just adds lots of duplication and becomes background noise. The framework will not magically make a person who writes example-style tests to suddenly start writing specification-style tests.
What about implementation-style tests? I have seen lots of implementation-style tests written in an "it should have" pseudo-specification-style like this:
Define person:
- it should have name
- it should not allow null name
- it should have age
- it should have address
- it should save
- it should load
- it should calculate pay
Writing implementation-style tests is still perfectly possible. A framework alone can't make the developer better. He must first understand the philosophy behind the framework and how to write expressive tests, before his tests will get any better.
Many testing frameworks get it wrong
behaviour-driven.org says that "Getting the words right" was the starting point for the development of BDD, so it is absurdly ironic that lots of BDD frameworks get the words wrong.
First and foremost, RSpec gets its words wrong by forcing the tests to start with "describe" and "it", as described above. And because RSpec has become popular and was one of the first BDD frameworks, lots of other BDD frameworks copy RSpec and use the same predefined words. They just repeat mindlessly what others have done, without stopping to think why the things were done that way. They become angry monkeys and cargo-cults, which annoy me very much.
Many BDD acceptance testing frameworks force the use of words "given", "when", "then". For example Cucumber does this. Decomposing actions into those three parts gives you state transition tables. This is a very explicit way of defining actions, but also very verbose. Added verbosity does not always make things easier to read; on the contrary, it can make it harder to see what is really important. As said in a famous quote:
In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.
- Antoine de Saint-Exupéry
And another one:
Many attempts to communicate are nullified by saying too much.
- Robert Greenleaf
I have even found a framework which adds predefined words as suffixes to the test names. In the Specs framework for Scala, the top-level test names end with "should", which is even printed in all the reports (unlike RSpec's "it"). Thankfully there is a workaround to avoid that suffix.
Frameworks should not limit the developer
A good testing framework will allow the developer to choose himself in what way he writes his test names. Some examples of testing frameworks, which do not force the use of predefined words, are JUnit 4 and JDave. But those two still force a fixed level of test nesting - JUnit 4 has no nesting and JDave has one level of nesting. Of the frameworks that I know, the least restrictive one is GoSpec, which I wrote myself with that as a goal.
When designing GoSpec, my goals were to allow unlimited levels of nesting, and to not force the test names to start with any predefined words. In Scala and other similarly expressive languages it would be easy to cope without any predefined words. For example I like in Specs the "test name" in { ... } style, which can also be written using an unpronounceable symbol "test name" >> { ... }. Unfortunately Go's syntax is not as flexible, so I was satisfied with prefixing each test name with "Specify". I chose that word to be such that starting a sentence with it would be totally unnatural, so that the developers would be inclined to just ignore it. Also all the examples of using that framework are written so that they do not include that word in the test names.
In a future article I will write about my current ideals for a unit testing framework. One of the primary goals is allowing the developer to use any style that is best for the situation, but there are also other goals (for a sneak peek, see the project goals in GoSpec's README).
By: Esko Luontola on: 2012-05-01 08:43:00 at: http://blog.orfjackal.net/2010/05/choice-of-words-in-testing-frameworks.html
Three Styles of Naming Tests
I have now used TDD for about 3 years, during which time I've come to notice three different styles of naming and organizing tests. In this article I'll explain the differences between what I call specification-style, example-style and implementation-style.
Tests as a specification of the system's behaviour
Specification-style originates from Behaviour Driven Development (BDD) and it's the style that I use 90% of the time. It can be found among practitioners of BDD (for some definition of BDD), so it could also be called "BDD-style". However, just using a BDD framework does not mean that you write your tests in this style. For example the examples on Cucumber's front page (no pun intended) are more in example-style than in specification-style. (By the way, I don't buy into the customer-facing requirements-analysis side of BDD, because in my opinion interaction design is much better suited for it.)
In specification-style the tests are considered to be a specification of the system's behaviour. The test names should be sentences which describe what the system should do - what are the system's features. Just by reading the names of the tests, it should be obvious that what the system does, even to such an extent that somebody can implement a similar system just by looking at the test names and not their body.
When a test fails, there are three options: (1) the implementation is broken and should be fixed, (2) the test is broken and should be fixed, (3) the test is not anymore needed and should be removed. If the test has been written in specification-style, then knowing what to do is simple. Just read the name of the test and decide whether that piece of behaviour is still needed. If it is, then you keep the same test name, but change the implementation or test code. If it is not, for example if the specified behaviour conflicts with some new desired behaviour, then you can remove the test and double-check all other tests in the same file, in case some of them should also be updated.
Here are some examples of specification-style tests (using Go and GoSpec). A test for Fibonacci numbers could look like this:
func FibSpec(c gospec.Context) {
fib := NewFib().Sequence(10)
c.Specify("The first two Fibonacci numbers are 0 and 1", func() {
c.Expect(fib[0], Equals, 0)
c.Expect(fib[1], Equals, 1)
})
c.Specify("Each remaining number is the sum of the previous two", func() {
for i := 2; i < len(fib); i++ {
c.Expect(fib[i], Equals, fib[i-1] + fib[i-2])
}
})
}
If you look at the Wikipedia entry for Fibonacci numbers, you will notice that the above test names are directly taken from there. This is how Wikipedia defines the Fibonacci numbers: "By definition, the first two Fibonacci numbers are 0 and 1, and each remaining number is the sum of the previous two. Some sources omit the initial 0, instead beginning the sequence with two 1s." The test names should document the same specification.
Each test focuses on a single piece of behaviour
One more example, in the same language and same framework, this time on stacks (ignore the comments for now). This is the style how I typically organize my tests:
func StackSpec(c gospec.Context) {
stack := NewStack()
c.Specify("An empty stack", func() { // Given
c.Specify("is empty", func() { // Then
c.Expect(stack.Empty(), IsTrue)
})
c.Specify("After a push, the stack is no longer empty", func() { // When, Then
stack.Push("foo")
c.Expect(stack.Empty(), IsFalse)
})
})
c.Specify("When objects have been pushed onto a stack", func() { // Given, (When)
stack.Push("one")
stack.Push("two")
c.Specify("the object pushed last is popped first", func() { // (When), Then
x := stack.Pop()
c.Expect(x, Equals, "two")
})
c.Specify("the object pushed first is popped last", func() { // (When), Then
stack.Pop()
x := stack.Pop()
c.Expect(x, Equals, "one")
})
c.Specify("After popping all objects, the stack is empty", func() { // When, Then
stack.Pop()
stack.Pop()
c.Expect(stack.Empty(), IsTrue)
})
})
}
(Note that GoSpec isolates the child specs from their siblings, so that they can safely mutate common variables. This was one of the design principles for GoSpec which enables it to be used the way that I prefer writing specification-style tests. The other important ones are: allow unlimitedly nested tests, and do not force the test names to begin or end with some predefined word.)
Each test has typically three parts: Arrange, Act, Assert. In BDD vocabulary they are often identified by the words Given, When, Then.
I've found it useful to arrange the tests so, that the Arrange and Act parts are in the parent fixture, and then have multiple Asserts each in its own test. Organizing the tests like this follows the spirit of the One Assertion Per Test principle (more precisely, one concept per test). When each test tests only one behaviour, it makes the reason for a test failure obvious. When a test fails, you will know exactly what is wrong (it isolates the reason for failure) and you will know whether the behaviour specified by the test is still needed, or whether it is obsolete and the test should be removed.
Quite often I use the words Given, When and Then in the test names, because they are part of BDD's ubiquitous language. But I always put more emphasis on making the tests readable and choosing the best possible words. So when it is obvious from the sentence, I may choose to
- omit the Given/When/Then keywords,
- group the Given and When parts together,
- group the When and Then parts together, or even
- group all three parts together.
In the above stack example, I have marked with comments that which of the specs is technically a Given, When or Then. As you can see, there is a distinct structure, but also much flexibility. The "should" word I dropped long time ago, after my second TDD project, because it was just adding noise to the test names without adding value. The value is in focusing on the behaviour, not in using some predefined words.
The specification should be decoupled from the implementation
Specification-style tests focus on the desired behaviour, or feature, at the problem domain's level of abstraction, and try to be as decoupled from the implementation as possible. The tests should not contain any implementation details (for example method names and parameters), because those implementation details are what will be designed after the test's name has been written. If the test's name already fixes the use of some implementation details (for example whether a method accepts null parameters), then refactoring the code will be harder, because it will force us to update the tests. Coupling tests to the implementation leads to implementation-style tests.
When the tests focus on the desired behaviour, then when refactoring, you won't need to change the name of the test, but only the body of the test (when refactoring affects the implementation's public interface). If you're doing a rewrite, then you may even be able to reuse the old test names - which is helpful, because thinking of the test name is what usually takes the most time in writing a test, because that is when you think about what the system should do. (If choosing the name does not take the most time, then you're not thinking about it enough, or you're writing too complex test code, which is a test smell that the production code is too complex.)
For example have a look at SequentialDatabaseAccessSpec and ConcurrentDatabaseAccessSpec. These are tests which I wrote 1½ years ago and in the near future the subsystem that those tests specify will be rewritten, as the application's architecture will be changed from being based on shared-state to message-passing and also the programming language will be mostly changed from Java to Scala. Here are the names of those tests:
SequentialDatabaseAccessSpec:
When database connection is opened
- the connection is open
- only one connection exists per transaction
- connection can not be used after prepare
- connection can not be used after commit
- connection can not be used after rollback
- connection can not be used after prepare and rollback
When entry does not exist
- it does not exist
- it has an empty value
When entry is created
- the entry exists
- its value can be read
When entry is updated
- its latest value can be read
When entry is deleted
- it does not exist anymore
- it has an empty value
ConcurrentDatabaseAccessSpec:
When entry is created in a transaction
- other transactions can not see it
- after commit new transactions can see it
- after commit old transactions still can not see it
- on rollback the modifications are discarded
- on prepare and rollback the locks are released
When entry is updated in a transaction
- other transactions can not see it
- after commit new transactions can see it
- after commit old transactions still can not see it
- on rollback the modifications are discarded
- on prepare and rollback the locks are released
When entry is deleted in a transaction
- other transactions can not see it
- after commit new transactions can see it
- after commit old transactions still can not see it
- on rollback the modifications are discarded
- on prepare and rollback the locks are released
If two transactions create an entry with the same key
- only the first to prepare will succeed
- only the first to prepare and commit will succeed
If two transactions update an entry with the same key
- only the first to prepare will succeed
- only the first to prepare and commit will succeed
- the key may be updated in a later transaction
If two transactions delete an entry with the same key
- only the first to prepare will succeed
- only the first to prepare and commit will succeed
When the above components are rewritten using a new architecture, new language and different programming paradigm, most of those test names will stay the same, because they are based on the problem domain of transactional database access, and not any implementation details such as the architecture, programming language, or *gasp* individual classes and methods.
In the above tests there will be only minor changes:
- The first fixture of SequentialDatabaseAccessSpec may be removed, or moved to some different test, because in the new architecture opening a database connection will be quite different (implicit instead of explicit). Actually it should have been put into its own test class, named DatabaseConnectionSpec, already when it was written, because it is very much different from the focus of the rest of SequentialDatabaseAccessSpec.
- In ConcurrentDatabaseAccessSpec, the test saying "on prepare and rollback the locks are released" will be removed, because the new architecture will not need any locks. The use of locks is an implementation detail and these specs were not fully decoupled from it.
What is a "unit test"?
The above example also raises the question about the size of a "unit" in a unit test. For me "a unit" is always "a behaviour". It never is "a class" or "a method" or similar implementation detail. Although following the Single Responsibility Principle often leads to one class dealing with one behaviour, that is a side-effect of following SRP and not something that would affect the way the tests are structured.
For those two test classes in the above example, the number of production classes being exercised by the tests is about 15 concrete classes (excluding JDK classes) from 2 subsystems (transactions and database). The lower-level components of those 15 classes have been tested individually (the transaction subsystem has its own tests, as well as do the couple of data structures which were used as stepping stones for the in-memory database) because the higher-level tests will not cover the lower-level components thoroughly, and I anyways wrote those tests to drive the design of the lower-level components with TDD. So the new code produced by those two test classes is about 5 production classes (originally it was about 3 production classes, but they were split to follow SRP).
From TDD's point of view, it's very important to be able to run all tests quickly, in a couple of seconds (more than 10-20 seconds will make TDD painful). On my machine SequentialDatabaseAccessSpec takes about 15 ms to execute (1.2 ms/test) and ConcurrentDatabaseAccessSpec about 120 ms (5.5 ms/test). I prefer tests which execute in 1 ms or less. If it takes much longer, then I'll try to decouple the system so that I can test it in smaller parts using test doubles. So to me the "unit" in a "unit test" is one behaviour, with the added restriction that its tests can be executed quickly.
More on specification-style
To learn more about how to write tests in specification-style, do the tutorial at http://github.com/orfjackal/tdd-tetris-tutorial and also have a look at its reference implementation and tests.
Update 2010-03-17: I just started reading Growing Object-Oriented Software, Guided by Tests and I'm happy to notice that also the authors of that book prefer specification-style. In chapter 21 "Test Readability", page 249, under the subheading "Test Names Describe Features", they have the following tests names:
ListTests:
- holds items in the order they were added
- can hold multiple references to the same item
- throws an exception when removing an item it doesn't hold
If you notice more books which use specification-style, please leave a comment.
Tests as examples of system usage
Example-style is perhaps the most popular among TDD'ers, maybe because many books, tutorials and proponents of TDD use this style. It's also quite easy to name tests with example-style, while at the same time being much better than implementation-style. I use this style maybe 10% of the time, usually to cover a corner case for which I have too hard a time to give a name using specification-style, or the specification-style name would be too verbose without added value as documentation. For some situations one style fits better than the other.
In example-style the tests are considered to be examples of system usage, or scenarios of using the system. The test names tell what is the scenario, and you will need to read the body of the test to find out how the system will behave in that scenario. The test names are not a direct specification, but instead to arrive at the specification, you will need to read the tests and reverse-engineer and generalize the behaviour that is happening on those tests.
A famous example which is written in example-style is Uncle Bob's Bowling Game Kata. There the test names are:
testGutterGame
testAllOnes
testOneSpare
testOneStrike
testPerfectGame
Now that you have read the test names, can you tell me the scoring rules of bowling? You can't? Exactly! That is what sets example-style apart from specification-style. In example-style you would need to reverse-engineer the scoring rules of bowling from the test code. In specification-style the test names would tell the scoring rules directly.
My domain knowledge about bowling is not good enough for me to write good specification-style tests for it, but it might look something like below. I took the scoring rules from the Bowling Game Kata's page 2 and reworded them some.
The game has 10 frames
In each frame the player has 2 opportunities (rolls) to knock down 10 pins
When the player fails to knock down some pins
- the score is the number of pins knocked down
When the player knocks down all pins in two tries
- he gets spare bonus: the value of the next roll
When the player knocks down all pins on his first try
- he gets strike bonus: the value of the next two rolls
When the player does a spare or strike in the 10th frame
- he may roll an extra ball to complete the frame
Here is another example of example-style, this time from JUnit's AssertionTest class.
arraysExpectedNullMessage
arraysActualNullMessage
arraysDifferentLengthMessage
arraysDifferAtElement0nullMessage
arraysDifferAtElement1nullMessage
arraysDifferAtElement0withMessage
arraysDifferAtElement1withMessage
multiDimensionalArraysAreEqual
multiDimensionalIntArraysAreEqual
oneDimensionalPrimitiveArraysAreEqual
oneDimensionalDoubleArraysAreNotEqual
...
This shows well a situation where example-style is useful: corner cases. In English it would be possible to describe the behaviour specified by AssertionTest with one sentence. Even though there are lots of corner cases, they all are semantically very similar. Writing these tests in specification-style would be impractically verbose. Here are the specification-style tests for a generic assertion:
When the expected and actual value are equal
- the assertion passes and does nothing
When the expected and actual value differ
- the assertion fails and throws an exception
- the exception has the actual value
- the exception has the expected value
- the exception has an optional user-defined message
Repeating that specification for every corner case is not practical, because it would just be more verbose but without any added documentation value. That's why in this case it would make more sense to write one use case with specification-style and the rest of the use cases in example-style (this is how I did it with GoSpec's matchers). Or since this particular problem domain is quite simple, just leave out the specifications and use only example-style.
Tests reflecting the implementation of the system
Implementation-style is typical in test-last codebases and with people new to TDD who are still thinking about the implementation before the test. I never use this style. It was only in my very first TDD project that I wrote also implementation-style tests (for example it had tests for setters), but at least I knew about BDD and was aware of my shortcomings and tried to aim for specification-style. (It took about one year and seven projects to fine-tune my style of writing tests, after which I wrote tdd-tetris-tutorial.)
In implementation-style the tests are considered to be verifying the implementation - i.e. the tests are considered to be just tests. There is a direction relation from the implementation classes and methods to the test cases. By reading the test names you will be able to guess that what methods a class has.
Typically the test names start with the name of the method being tested. Since nearly always more than one test case is needed to cover a method, people tend to append the method parameters to the test name, or append a sequential number, or *gasp* put all test cases into one test method.
As an example of implementation-style, here are some of the test cases from Project Darkstar's TestDataServiceImpl class. I know for sure that Darkstar has been written test-last, in addition to which mosts of its tests are integration tests (it takes 20-30 minutes to run them all, which makes it painful for me to make my changes with TDD).
testConstructorNullArgs
testConstructorNoAppName
testConstructorBadDebugCheckInterval
testConstructorNoDirectory
...
testGetName
testGetBindingNullArgs
testGetBindingEmptyName
testGetBindingNotFound
testGetBindingObjectNotFound
testGetBindingAborting
testGetBindingAborted
testGetBindingBeforeCompletion
testGetBindingPreparing
testGetBindingCommitting
testGetBindingCommitted
...
From the above test names it's possible to guess that there is a class DataServiceImpl which has a constructor which takes as parameters at least an app name, a debug check interval and some directory. It's not clear which are the valid values for them and whether null arguments are allowed or not. Also we can guess that the DataServiceImpl class has methods getName and getBinding, the latter which probably takes a name as parameter. With getBinding it's possible that "something is not found" or "an object is not found". The getBinding method's behaviour also appears to depend on the state of the current transaction. It's not clear how it should behave in any of those states.
Implementation-style is bad compared to example-style and specification-style, because implementation-style is not useful as documentation - it does not tell how the system should behave or how to use it - which in turn makes it hard to know what to do when a test fails. Also implementation-style couples the tests to the implementation, which makes it hard to refactor the code; if you rename a method, you need to also rename the tests. If you do big structural refactorings, you must rewrite the tests. And when you rewrite the tests, the old tests are of little benefit in knowing which new tests to write.
Summary
Specification-style test names describe how the system will behave in different situations. By reading the test names it will be possible to implement the system. When a test fails, the test name will tell which behaviour is specified by that test, after which it's possible to decide whether that test is still needed. The test names use the problem domain's vocabulary and do not depend on implementation details.
Example-style test names describe which special cases or scenarios the system should handle. You will need to read the body of the test to find out how the system should behave in those situations.
Implementation-style test names tell what methods and classes the system has. It will be very hard to find out from the tests that which situations the system should handle and how it should behave in those situations. Refactorings require you to change also the tests.
By: Esko Luontola on: 2012-05-01 08:41:27 at: http://blog.orfjackal.net/2010/02/three-styles-of-naming-tests.html
A Mentoring Story
In the Spring of 2002, I was enthralled by the software development community that had grown up around the ideas in Kent Beck’s book eXtreme Programming Explained. This was my first exposure to a software development “process”, so I sought out the local XP community to learn more. I quickly found ChAD, the Chicago Agile Devleopers group and started attending regularly. After one of my first meetings, I introduced myself to the group’s leader (with a shaky hand and untold waves of anxiety). His name was Wyatt Sutherland. I offered to help Wyatt with the group, which mostly meant moving chairs and lugging 12-packs of Coke to meetings. A month or two later, I told Wyatt that I wanted to “apprentice” under him. Neither of us really knew what that meant, and I can’t even remember his response. But I do remember that we started meeting for lunch or breakfast periodically after that.
Later that year, I saw an opportunity to convince my employer that we should try an XP pilot project. I told Wyatt about my plan, but admitted that I was in over my head. He reassured me that I could pull it off. This helped focus our breakfast conversations for a while, which was a thrill since this was the closest we ever came to working together. Eventually I pitched the pilot project and it was given the green light. The experience I gained through that project was a result of the confidence Wyatt helped create in me. That experience propelled me into ThoughtWorks a year later, which was my “big break” as a software developer.
A decade later, when I look back on that time with Wyatt, though, the aspects of our relationship that have stuck with me aren’t about software or technology. I saw in Wyatt more than a software developer or community leader. He is a man with a full life. Wyatt is a father of four, a husband, a musician, and a technologist. One of the highlights of my relationship with him was bringing my wife to a string quartet he was playing in. Wyatt is a world-class cellist. Listening to him play that night was inspiring. I arrived with an assumption that Wyatt was a software developer with a cello hobby. I left the concert with a vision for a full and integrated life for myself.
Thanks Wyatt for your encouragement, your example, and for your time.
This was posted as part of the Mentoring Story exercise from the apprentice.us mailing list.
By: on: 2012-05-01 01:40:00 at: http://nuts.redsquirrel.com/post/22164367441
A Scope Heuristic
One of my first exposures to TDD was through a code kata. I was mortified.
The performer test-drove his way to a simple function for factoring prime numbers. He added tests one by one:
- It should factor 1 correctly
- It should factor 2 correctly
- ...
To me, the order in which the tests were added did not suggest any pre-meditated approach. It did not suggest any deep understanding of the problem domain. The performer did not seem to think that writing a factorization function required any forethought at all! "If I were to test drive this problem," I thought, "I would at least start by test-driving the helper function that is necessitated by my Algorithm. When the kata was over, nobody voiced any of the criticisms I had. I was upset and confused.
My feelings on TDD have evolved somewhat since then. I have become significantly more enthusiastic about the practice, but I am still trying to understand how exactly it is helpful. In particular, that day's kata illustrated a tension which I have not resolved for myself.
This tension is between thinking far ahead, and focusing on immediate concerns, when test-driving a change. In some cases, it's clear that you need to leave the computer and think through your options. In others, it's clear that you need to start typing and let the software evolve.
Some of my most frustrating software development experiences have been rooted in this tension. I have been burned by my lack of foresight: it has allowed me to let poor design decisions cement. Conversely, I have spent hours fretting about which approach to take, only to find out that my worries were ultimately irrelevant.
Perhaps you are thinking to yourself that the answer is obvious: always put a lot of thought into your changes. If so, I agree with you, but you are missing the point! One of the benefits of TDD is that it can keep me from thinking too far ahead; it does not cause me to think any less. Sometimes, by shortening my sights, TDD will prevent me from writing complicated things that I don't need, or from worrying about non-issues.
I am slowly learning to distinguish the situations where I can reap this benefit from those where I cannot.
I would like to suggest a rough classification of the situations where it makes sense to embrace short-term thinking.
- When a coding decision is tightly coupled to the structure of existing code, and is cheap to revise, you should try to reap the benefits of short-term thinking.
- When a coding decision is costly to revise, you should not try to reap the benefits of short-term thinking.
Decisions coupled to the problem domain, for example, often fall into category 2. There is often a high price to pay for misunderstanding the problem domain, because this understanding informs your high-level approach. Moreover, thinking deeply about the entire problem domain can yield high returns.
Refactoring tasks often force you to make decisions which fall into category 1. When you refactor incrementally, it should be cheap to revise any mistakes that you make. Moreover, it is hard to accurately anticipate the outcome of a refactor. You have to interact with the codebase to know what approach to take, and the best way to do this is by test-driving small changes.
Where does this classification hold up?
Suppose, for example, that you would like to write an AI module for a zero-sum two-player board game. This task is tied to the problem domain, and long-term thinking can pay dividends. If you choose the wrong algorithm, you will have to rewrite essentially the entire module; this task therefore falls into category 2.
Without thinking far ahead, you could test-drive your way to a module that works pretty well. Unfortunately, you are liable to write tests haphazardly, producing an inelegant pile of control flow statements. Once you choose to use an algorithm based in game theory, your approach crystallizes. It's easy to start working methodically towards a solution, with tests along the lines of,
- The AI looks 0 moves into the future.
- The AI looks 1 move into the future.
- The AI looks arbitrarily into the future.
Now, suppose you anticipate duplicating code in the next feature that you add to this two-player game. Maybe you think that the "game over" function in your main game loop will resemble the "stop searching into the future" function of your AI module. The anticipated refactor will require you to think about the structure of the existing code. This refactor will also (hopefully) be cheap to revise; it therefore falls into category 1.
It would be a bad idea to jump ahead and spec out a function which eliminates duplication. It makes more sense to focus on immediate concerns, adding the feature so that the duplicated code exposes itself. Even as I write this article, I am creating and eliminating duplication.
Where does this classification fail?
This classification essentially falls apart when it comes to deciding how information should travel through a program. I will refer to this as software "workflow". Decisions about software workflow do not fall cleanly into either side of my classification, and I am not sure how to approach making them. Why don't decisions about workflow fall cleanly into either side of the classification?
First, workflow decisions are very costly to revise. Changing existing workflow can be extremely difficult because it involves updating interfaces; this can break your dependency inversion measures, requiring you to make cascading changes [1]. Workflow, therefore, fits into category 2.
Second, workflow is tightly coupled to the code that you write. Your workflow decisions dictate which modules exist and what their interfaces look like. Consequently, you cannot think very deeply about workflow without getting tripped up by complications in the existing code. So workflow decisions also partially fit category 1.
What can we learn from our inability to classify decisions related to workflow? I think we have gained an understanding of why workflow is hard to get right. Workflow is complicated, so it demands incremental evolution. Existing workflow is also extremely hard to alter, so incremental evolution can be costly and difficult.
Conclusion
It is unfortunate that my heuristic does not apply to every challenge a developer faces. I think that my heuristic will offer some value to developers who, as I once was, are confused about the benefit of test-driven development.
[1] For more information on why workflow is costly to revise, see the discussion of the StableDependencies principle in PPP. In the nomenclature of the text, changes to workflow often result in changes to "stable" pieces of software.
By: wai lee chin feman on: 2012-05-01 00:00:00 at: http://8thlight.github.com/wai-lee-chin-feman/2012/05/01/a-scope-heuristic.html
Monday April 30, 2012
Slides from my "Introduction to Rubinius" Talk
Earlier today I gave a talk at the Israeli Ruby Underground meetup about Rubinius, including a quick hacking session showing how one can remove else from unless. Below you can find the slides.
As every hacker I strive to become better, so if you attended the talk I’d greatly appreciate it if you would spare a minute and rate it here.
You should subscribe to my feed or follow me on twitter!
By: on: 2012-04-30 17:54:00 at: http://feedproxy.google.com/~r/TheCodeDump/~3/ePvHnstzdQU/
Why I Chose to be an Apprentice
Last year, when I was looking for post-graduation jobs, I had no idea that I would end up at 8th Light. I went to a lot of career fairs and interviewed with a lot of companies. After a while I was offered a job by a company located in downtown Chicago. It was a .NET shop specializing in enterprise eDiscovery software. Even though I had no idea what that meant at the time, they offered me a good salary and I thought that the .NET world would be a fun adventure. So, I accepted the job and moved to Chicago after graduation.
I worked there for 6 months. The company was great and I enjoyed my time there, but, it became apparent to me very quickly that the enterprise .NET world was not for me.
After a few months of searching for a new job, I stumbled across 8th Light. I was immediately attracted to the idea of Craftsmanship. I wanted to be a part of their passionate and skilled group of developers. It seemed like the perfect fit. I submitted a Tic-Tac-Toe and an application without too much hope, but to my surprise I was offered a Resident Apprenticeship.
Choosing whether or not to become an apprentice at 8th Light was hard. There were a few things that made me nervous about joining. First, 8th Light apprentices are not paid as much as the Craftsman, which meant that I would have to take a pay cut to become an apprentice. At the time, my wife was unemployed, so taking on a new job that paid less would be a stretch on the budget. Second, there was no guarantee that I would be hired on as a Craftsman after completing the apprenticeship. This uncertainty was my biggest concern about becoming an apprentice. Coming to 8th Light meant that I would get paid less, work a lot harder, take out the trash, do the dishes, and still have no guarantee of a job in six months. I wasn't sure if I could do it. But here's what made me take the leap.
8th Light is committed to teaching apprentices how to be skilled and passionate software developers. Because of this commitment, there is no better place to learn and grow. I realized that, even if I was not offered a job at the end of my apprenticeship, my time at 8th Light would not have been wasted; spending a few months in an environment geared towards my professional growth would be better for my career than spending a few more months in my old job. And at the end, the experiences and skills that I gained as an apprentice would be invaluable to future employers. The decision was obvious, I had to be an apprentice.
In retrospect, the apprenticeship was very challenging, but I am extremely grateful that I accepted. Now that I am a Craftsman, my experiences as an apprentice mean even more to me. It was a great time of personal and professional growth; I cannot imagine myself without it. If you find yourself in a position like mine, do not fear the uncertainty of apprenticeship. You can only gain from spending some time learning from the Craftsmen at 8th Light.
By: myles megyesi on: 2012-04-30 00:00:00 at: http://8thlight.github.com/myles-megyesi/2012/04/30/why-i-chose-to-be-an-apprentice.html
Thursday April 26, 2012
Pair Programming Madness
Pair programming madness (or musical chairs for programmers)
I've been meaning to write about this game I developed at the Boston Software Craftsmanship Meetings for a long time and apparently the time for writing is now! It's a fun, silly, chaotic way to pair with friends and strangers. Without further ado here's the description:
Pair programming madness is a collaborative coding game similar to musical chairs.
Rules:
- Select a code kata. At Boston SC we've used: https://github.com/moss/messaging-exercise and found it well suited.
- Everyone brings a laptop with their favorite language setup with a testing framework
- Present a code kata and everyone pairs up
- We’ll work on the kata for 15 minutes, then rotate pairs. One person stays + one person goes
- Repeat step 4
What's this look like? Well, you'll only work on one code base max 2 times and pair with 3-4 different people. Additionally you'll both be in the position of explaining current (legacy) code to a new pair or coming up to speed with a code base / env you're not familiar with. (Basically controlled chaos, but fun)
Important note: Because it’s possible that two people will be working in a language + env that they’re not familiar with, you should make sure to have either an easy to use IDE, that’s kind of point and clicky or a vanilla text editor (no vim / emacs) and an easy way to run the tests.
Running 3 iterations will take ~90 minutes.
Enjoy!
I've been meaning to write about this game I developed at the Boston Software Craftsmanship Meetings for a long time and apparently the time for writing is now! It's a fun, silly, chaotic way to pair with friends and strangers. Without further ado here's the description:
- Select a code kata. At Boston SC we've used: https://github.com/moss/messaging-exercise and found it well suited.
- Everyone brings a laptop with their favorite language setup with a testing framework
- Present a code kata and everyone pairs up
- We’ll work on the kata for 15 minutes, then rotate pairs. One person stays + one person goes
- Repeat step 4
By: Zachary D. Shaw on: 2012-04-26 18:29:22 at: http://feedproxy.google.com/~r/blogspot/zdsbs/~3/xTp7VG-Tbis/pair-programming-madness.html
Polymorphism in Clojure
“polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface” -Wikipedia
In most Object Oriented programming languages, polymorphism is tied to inheritance. In Clojure however, the concept of concrete inheritance is not built into the language. So, when I was first learning Clojure, it was hard for me to use my previous knowledge of polymorphism in the functional world. No need to fear, Clojure provides great methods for achieving polymorphism without using concrete inheritance.
As an example, this is a simple function that takes basic Clojure data and converts it to JSON.
1 (defn convert [data]
2 (cond
3 (nil? data)
4 "null"
5 (string? data)
6 (str "\"" data "\"")
7 (keyword? data)
8 (convert (name data))
9 :else
10 (str data)))
This works, but it is not polymorphic. So let's take a look at a few ways to improve this.
Multimethods
A Clojure multimethods is a combination of a dispatch function and one or more methods, each defining its own dispatch value. The dispatching function is called first, and returns a dispatch value. This value is then matched to the correct method. Lets take a look at our previous example refactored into a multimethod.
1 (defmulti convert class)
2
3 (defmethod convert clojure.lang.Keyword [data]
4 (convert (name data)))
5
6 (defmethod convert java.lang.String [data]
7 (str "\"" data "\""))
8
9 (defmethod convert nil [data]
10 "null")
11
12 (defmethod convert :default [data]
13 (str data))
Awesome! We have our first polymorphic solution. Now we can add more data types without altering the existing functions. Let's add a method for vectors as well.
1 (defmethod convert clojure.lang.PersistentVector [data]
2 (str "[" (join ", " (map convert data)) "]"))
Now we can also convert vectors into JSON.
There is another feature of multimethods that we can use to extend this solution further. Multimethods actually use the isa? function instead of the = function to match dispatch values to the correct method. This yields a very important feature, hierarchies. Let's open up the REPL and take a look at the classic Shape example,
1 user=> (derive ::rect ::shape)
2 nil
3 user=> (derive ::circle ::shape)
4 nil
5 user=> (isa? ::circle ::shape)
6 true
7 user=> (isa? ::rect ::shape)
8 true
Now let's see if we can apply this hierarchy system to our previous vectors method.
1 (derive clojure.lang.PersistentVector ::collection)
2
3 (defmethod convert ::collection [data]
4 (str "[" (join ", " (map convert data)) "]"))
With this hierarchy, any type that matches ::collection will dispatch to the same method as vectors. Since there is no there is no difference between a list and vector in JSON, we can convert them to JSON in the same way, so we simply make PersistentList derive from ::collection as well.
1 (derive clojure.lang.PersistentList ::collection)
We were able to extend the multimethod to handle Lists with one line!
Its also worth noting that we could implement the same functionality without introducing hierarchies here. List and vectors already share many common interfaces, so we could use one of those instead. We simply replace our vector method with this
1 (defmethod convert clojure.lang.Sequential [data]
2 (str "[" (join ", " (map convert data)) "]"))
Now we’re able to convert vectors and lists without using hierarchies.
Another great feature that is hard to demonstrate here is that the methods do not have to be defined in the same file as their dispatch function. This allows us to extend the functionality of multimethods that are defined elsewhere in the system or even in a 3rd party library.
Multimethods can be very useful in situations where you cannot change the clients of a function. For instance, if there are thirty other functions using the convert function, it is hard to change. However, we can refactor into a multimethod without changing any of the clients. This allows us to refactor safely without affecting any clients.
In my experience, multimethods are best used in cases where you only need to define one polymorphic function. When multimethods are used to define a group of polymorphic methods, this solution can get a little messy. However, Clojure provides great facilities for this as well, namely Protocols.
Protocols
Another way to improve our original switch statement is though Protocols. Protocols will be a little more familiar for those coming from Object Oriented languages, as they are very similar to interfaces. Let's look at our original function refactored to use a Protocol.
1 (defprotocol JSON
2 (to-json [this]))
3
4 (extend-protocol JSON
5 java.lang.Boolean
6 (to-json [this]
7 (str this))
8
9 java.lang.Long
10 (to-json [this]
11 (str this))
12
13 java.lang.Double
14 (to-json [this]
15 (str this))
16
17 java.lang.String
18 (to-json [this]
19 (str "\"" this "\""))
20
21 clojure.lang.Keyword
22 (to-json [this]
23 (to-json (name this)))
24
25 nil
26 (to-json [this]
27 "null"))
In this example, we define a Protocol, JSON, which has one method, to-json. Then we use the helper macro extend-protocol to extend all of our types at once. Now, we can simply call the to-json method directly on the data types themselves rather than through a conversion function.
1 user=> (to-json "1")
2 "\"1\""
3 user=> (to-json 1)
4 "1"
In the same way that interfaces are used in conjuction with classes in Java and C#, protocols, in conjunction with deftype or defrecord, can be used to define an explicit API that a type implements. For example,
1 (defprotocol Dog
2 (sit [this])
3 (bark [this])
4 (eat [this]))
5
6 (deftype Terrier []
7 Dog
8 (sit [this]
9 (prn "sitting"))
10 (bark [this]
11 (prn "woof!"))
12 (eat [this]
13 (prn "nom nom nom!")))
14
15 (defn new-terrier []
16 (Terrier.))
Using this method, we can kind of mimic objects. Terrier can be instantiated and used just like any other object.
1 user=> (def terrier (new-terrier))
2 #'user/terrier
3 user=> (bark terrier)
4 "woof!"
5 nil
6 user=> (sit terrier)
7 "sitting"
8 nil
9 user=> (eat terrier)
10 "nom nom nom!"
11 nil
Even though I don’t like mimicking objects in Clojure, sometimes it is necessary in order to use Java interfaces and objects, which you can learn more about here.
As with multimethods, type definitions do not have to be defined in the same file as their protocol definition, allowing us to implement protocols defined in other libraries.
As seen in the Dog/Terrier example, Protocols are great for encapsulating a group of related methods into one polymorphic package. However, this method of polymorphism should be used sparingly. Protocols are often abused to mimick an Object Orient approach because it is a familiar solution. However, if you do this, you will often miss out on the simplest solution, pure functions.
Functions as parameters
This is simplest form of polymorphism in Clojure. By accepting a function as a parameter, the given function proide multiple solutions with one interface (the parameters). Instead of refactoring our original function, let's consider a context in which it is commonly used. Web servers often need to convert data structures into JSON before returning them to clients. So let's consider a resource controller, which has an action to create a User given the request parameters.
1 (defn create [params]
2 (let [user (build-user params)
3 user (save user)]
4 (convert-to-json user)))
This function simply takes the request params, builds a user model out of them, saves them to the database and returns the result as JSON. We can make this controller polymorphic by accepting the JSON converter function as a parameter to the create function instead of calling it directly.
1 (defn create [params converter]
2 (let [user (build-user params)
3 user (save user)]
4 (converter user)))
Now the create function doesn’t have to know anything about the structure of the data that is returned to the user. The given converter function is polymorphic, meaning that it can convert the data into whatever format the user requests, instead of just JSON. So if the user requests XML or HTML instead of JSON, we don’t need to alter our create function; we simply need to pass in a different converter.
Conclusion
Using functions as parameters is by far my favorite form of polymorphism in Clojure. It is this simplest and most consise of all three methods; I try to use this method whenever possible. However, Multimethods and Protocols are equally powerful and provide useful ways in which to design polymorphic systems without concrete inheritence. With these methods in your tool belt, you don't have to feel as lost as I did when coming into the world of Clojure.
By: myles megyesi on: 2012-04-26 00:00:00 at: http://8thlight.github.com/myles-megyesi/2012/04/26/polymorphism-in-clojure.html
Ruby Accessors Considered Pernicious
One Ruby feature I fell in love with is the ability to define methods like foo and foo= which are used like simple variable accessors. This can be a very powerful abstraction. Yet now I'm convinced that putting logic in these accessors is often the wrong tool for the job.
foo and foo= which are used like simple variable accessors. This can be a very powerful abstraction. Yet now I'm convinced that putting logic in these accessors is often the wrong tool for the job.
The entire beauty of such methods is that they appear to be simple accessors, emulating a struct, but they can execute arbitrary logic behind the scenes. This means you can define Tweet#text and it can pretend to have its content on hand, while in reality it's actually making an HTTP request!
The problem is, life isn't that simple. Anything more complex than an actual getter or setter, whether reading the contents of a file, making an HTTP or TCP request, or executing some SQL, has the capacity to fail.
And when these actions fail, we typically have some Plan B that's not just "oh no everyone panic!" (which is exactly what letting the exception get to the top level does). Plus, it's unsightly to wrap simple accessor expressions in begin/rescue/end blocks.
There are also times when an API doesn't make it clear that some expression which looks like a simple accessor actually has the potential to throw custom exceptions of some kind. This is especially true when we learn about an API via pry or some other dynamic introspection tool. So even if we wanted to, we might not even realize that we need to wrap such a statement with a rescue block.
A simple and effective alternative is to execute such actions using explicit, non-accessor methods. Instead of every accessor on Tweet making real HTTP requests, they could really be simple accessors. We could then add two new methods, #save and #load, which could do the HTTP interaction and store fetched data on the object. If we designed our API like this, all of Tweet's methods would benefit from having an obvious and predictable behavior.
Custom accessors are great when dealing with calculated or derivative fields, such as deriving full_name when you already have first_name and last_name, or for various mathematical calculations. We should be kind to our fellow developers and design our APIs to be predictable by restricting our usage of custom accessor-like methods to these trivial cases and leaving the heavy lifting to explicit methods.
By: steven degutis on: 2012-04-26 00:00:00 at: http://8thlight.github.com/steven-degutis/2012/04/26/ruby-accessors-considered-pernicious.html
Wednesday April 25, 2012
Guest post: Specialized Skills
About the Author: George Dinwiddie is an independent software consultant and coach working for [his own business] iDIA Computing. I first “met” George on the notorious Scrum Development email list where I was impressed with his well-reasoned opinions, delivered at a measured pace. In his own words:
I am a software development consultant and coach with over thirty years of experience creating software ranging from small embedded systems to corporate enterprise systems. With a strong interest in lifelong learning, I have pursued more effective ways of creating software at the technical, interpersonal and organizational levels. My specialty is helping teams become more effective while helping them accomplish their current project. I practice consulting, coaching, mentoring, teaching and training.
You should check out more great articles by George on his blog at http://blog.gdinwiddie.com/.
I am a software development consultant and coach with over thirty years of experience creating software ranging from small embedded systems to corporate enterprise systems. With a strong interest in lifelong learning, I have pursued more effective ways of creating software at the technical, interpersonal and organizational levels. My specialty is helping teams become more effective while helping them accomplish their current project. I practice consulting, coaching, mentoring, teaching and training.
You should check out more great articles by George on his blog at http://blog.gdinwiddie.com/.
Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.
But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. It’s like having a small box of crayons. 
One person takes the red crayon, others orange, yellow, green, blue, and violet. With that, we try to create a glorious full-color work of art. It’s no surprise that’s hard to do.
Colors in the real world flow from one named color to another, without a discernible boundary. It’s a continuous spectrum 
to which we’ve given names at certain approximate points. You just can’t draw the world as we see it using only six crayons.
The typical corporate response is to add more crayons. 
And more people to hold those crayons. And more delays caused by passing things from one person to another. And… we still don’t get the picture we want. The more people we have, and especially the more specialists, the harder it is to get a pleasing cohesive picture.
We 
don’t need to eliminate specialization, though. Just blur the boundaries a little. We can get the full-color rendition we want with our limited palette if we blend the colors where they meet.
Rather than pass the work from one type of the work to the next, let the people doing those different types of work work together. They might even swap colors with each other from time to time. Odds are, they’ll do a much better job at producing the picture you want.
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: kane on: 2012-04-25 20:01:00 at: http://feedproxy.google.com/~r/Scrumology/~3/UWSuenPtkbE/
Apprenticeship Over College
I interviewed a bright young woman today who is graduating from high school this spring among the top of her class. Despite having several generous scholarships at her disposal, she is considering an 8th Light apprenticeship.
"You can't tell her not to go to college!" people would scold me. So I began thinking... and concluded that college is not all it's cracked up to be these days.
1. College is not affordable. It was expensive when I was in school 15 years ago. Today it costs about three times as much. How do students afford that? Student Loans of course. But how discouraging! The majority of young adults get to start their adult lives with a mountain of debt.
TechPaladin - Sourced from NCES
2. A college degree doesn't differentiate you. The good news is that the U.S. is more educated than ever before. The bad news is that your college degree is one in a million. Sure, fifty years ago a 4-year degree made you stand out big-time, Mr. Smarty Pants. Today though, a 4 year degree just makes you an average Jane.
A college degree is not so special these days.
3. A College education doesn't guarantee a good job. Most of us grew up hearing the mantra: "Work Hard. Go to School. And you'll get a good job." Well, this was one of the hot topic of the recent Occupy Movement. People were protesting because they did work hard, they did go to school, and well, they didn't have a good job!
4. College doesn't prepare you for a career in software. This may be true for other industries, but I speak from experience with regard to the software industry. After earning a 4 year degree in Math and Computer Science, I got a job as a software engineer, and the sad truth was I had no clue how to develop the first project assigned to me. Fortunately I had great mentors to help me along.
12 years later I have interviewed countless college grads. Some amaze me with their experience and ability, but the majority are as clueless as I was.
What's a high school grad to do?
The social pressure to go to college is immense. I asked people, "Knowing what you know today, would you still have gone to college? And they told me "Yes! Because my parents would not have allowed otherwise." Even my brother, who dropped out of school to work with me, eventually quit and went back to school because of the pressure our mother put on him.
Yet, this high school grad must consider that although 4 years in college does earn her that conventional degree, it also means a huge debt, no guarantee of a job, and no real-world preparation for the work place.
8th Light Apprenticeship
The "Go to School" mindset is instilled in me to the point where I cannot in good conscience tell people NOT to go to college. Yet I can happily state the advantages of 8th Light's Apprenticeship program and, without any guilt, hire a young apprentice who decides not to go to college. That is, if they get accepted into the program.
What are the advantages?
- No debt
- We pay you
- You gain real-world experience
- You will be more skilled and more marketable in the software industry than your college faring peers
- Full salary Craftsman position in a year or two
- A network of contacts in the software industry
While pondering this whole issue, I came across one of our apprentices blog entry that included an RSA Animate video on education. It's a good video; watch it. In summary it says that our modern education system is broken and that we need a change. 8th Light's Apprenticeship may not be the answer, but it seems to be filling a niche.
By: micah martin on: 2012-04-25 00:00:00 at: http://8thlight.github.com/micah-martin/2012/04/25/apprenticeship-over-college.html
Apprenticeship Over College
I interviewed a bright young woman today who is graduating from high school this spring among the top of her class. Despite having several generous scholarships at her disposal, she is considering an 8th Light apprenticeship.
"You can't tell her not to go to college!" people would scold me. So I began thinking... and concluded that college is not all it's cracked up to be these days.
1. College is not affordable. It was expensive when I was in school 15 years ago. Today it costs about three times as much. How do students afford that? Student Loans of course. But how discouraging! The majority of young adults get to start their adult lives with a mountain of debt.
TechPaladin - Sourced from NCES
2. A college degree doesn't differentiate you. The good news is that the U.S. is more educated than ever before. The bad news is that your college degree is one in a million. Sure, fifty years ago a 4-year degree made you stand out big-time, Mr. Smarty Pants. Today though, a 4 year degree just makes you an average Jane.
A college degree is not so special these days.
3. A College education doesn't guarantee a good job. Most of us grew up hearing the mantra: "Work Hard. Go to School. And you'll get a good job." Well, this was one of the hot topic of the recent Occupy Movement. People were protesting because they did work hard, they did go to school, and well, they didn't have a good job!
4. College doesn't prepare you for a career in software. This may be true for other industries, but I speak from experience with regard to the software industry. After earning a 4 year degree in Math and Computer Science, I got a job as a software engineer, and the sad truth was I had no clue how to develop the first project assigned to me. Fortunately I had great mentors to help me along.
12 years later I have interviewed countless college grads. Some amaze me with their experience and ability, but the majority are as clueless as I was.
What's a high school grad to do?
The social pressure to go to college is immense. I asked people, "Knowing what you know today, would you still have gone to college? And they told me "Yes! Because my parents would not have allowed otherwise." Even my brother, who dropped out of school to work with me, eventually quit and went back to school because of the pressure our mother put on him.
Yet, this high school grad must consider that although 4 years in college does earn her that conventional degree, it also means a huge debt, no guarantee of a job, and no real-world preparation for the work place.
8th Light Apprenticeship
The "Go to School" mindset is instilled in me to the point where I cannot in good conscience tell people NOT to go to college. Yet I can happily state the advantages of 8th Light's Apprenticeship program and, without any guilt, hire a young apprentice who decides not to go to college. That is, if they get accepted into the program.
What are the advantages?
- No debt
- We pay you
- You gain real-world experience
- You will be more skilled and more marketable in the software industry than your college faring peers
- Full salary Craftsman position in a year or two
- A network of contacts in the software industry
While pondering this whole issue, I came across one of our apprentices blog entry that included an RSA Animate video on education. It's a good video; watch it. In summary it says that our modern education system is broken and that we need a change. 8th Light's Apprenticeship may not be the answer, but it seems to be filling a niche.
By: micah martin on: 2012-04-25 00:00:00 at: http://8thlight.github.com/micah-martin/2012/04/25/apprenticship-over-college.html
Monday April 23, 2012
Installing Realtek USB WiFi drivers on Mac OS Lion
The airport card in my laptop died and I couldn't get it fixed before going away for a week. So I needed a stop-gap solution. There are many USB wifi adaptors on eBay that claim Mac compatibility. Some are super-cute little things that only just stick out of the USB port (how they have enough antenna showing to get a signal is anyone's guess).
They almost all seem to use a Realtek chipset. (You can verify this by going to System Information on your Mac, opening the Hardware>USB page, and selecting the device. The bottom pane shows the device info, included the manufacturer name (look at the Vendor ID line).
If you're lucky, you'll get a driver CD bundled. If you're very lucky it's even got some Mac drivers on it.
Don't even try to use them! They'll be hideously out of date.
And don't go to the Realtek website and download the driver that matches your chip number. no doubt that too will be hideously out of date.
I wasted hours doing that; it reminded me of why the Mac is (usually) a so much better computing environment that Windows and Linux. I wasted hours fiddling with different driver versions, 32-bit and 64-bit kernels, cleaning out old driver installations, Googling forum postings, trying other driver versions, and all sorts of tedious tomfoolery.
The simple solution I found, which works on Lion, with 64 bit kernels and 32 bit kernels, is to install the following Realtek driver:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true
Select the RTL8188CUS>Others>Mac OSX 10.7 Install Package (UI ver 1.9.7) version.
Even though the chip number doesn't match my USB key, the software is perfectly compatible with older devices. And it has the added bonus of working.
Remember: the driver doesn't integrate into Apple's airport utility. So you'll have to run a separate client to set up the wireless network. It isn't pretty. But it works.
By: Pete Goodliffe on: 2012-04-23 08:17:00 at: http://goodliffe.blogspot.com/2012/04/installing-realtek-usb-wifi-drivers-on.html
Friday April 20, 2012
Using Evernote for Fun and Profit
I wanted to share how much I’m in love with the collection of bits called Evernote. It is by far one of the best lifehacks I’ve found in the past year and I just had to spread the word to those that haven’t started using it yet.
Evernote basically allows you to move a lot of the data you keep in your head, drawers, phone etc. to it, thus enabling you to free your really expensive brain GBs and make your life easier and less stressful. I’d like to mention that even though Evernote has a premium plan, I’m using the free plan for everything that I’m going to describe and it still kicks butt.
Real examples of how much awesome I get from Evernote
- I no longer keep bills, letters etc. around after I read them just in case I’ll need them. I scan them or even just snap it with my iPhone and put it on Evernote. Evernote automatically OCRs the text so that I can even search it later, and I get rid of paper I don’t want to keep.
- When the washing machine technician came over to teach us how to use it, I just created a new audio note on Evernote and recorded his explanation. I knew I’m terrible at remembering these things and didn’t even bother. Now I’ve got it and every time I need to remember what that little thingie does, I can check.
- I’ve got the Evernote Web Clipper extension on Chrome that allows me to save a web page or a part of it to Evernote with the click of a button, so that every reference material I can ever look for is instantly saved.
- I’m using ifttt to automatically save every tweet I favorite to Evernote - making favorites useful again.
- You can get a specific email address from Evernote that takes whatever you mail it and creates a note out of it. I’ve saved this in my contacts as “QQQ” meaning it takes me less than 5 seconds to save every little idea the comes to mind.
- You can search all of this stuff super fast. Evernote is basically the best reference material storage system I could think of. This with the quick-emailing trick allows for a great Getting Things Done set up.
- And last but not least, Evernote magically works everywhere - on my mac, my phone and my iPad. Meaning I easily snap a recipe on my mac and then take the iPad with me to the kitchen and it’s right there. I can quickly get whatever I need on the go on my phone. Just geek joy!
Do yourself a solid and start using it ASAP. I’m not getting a dime out of this, it’s really that good it deserves this post!
You should subscribe to my feed or follow me on twitter!
By: on: 2012-04-20 14:55:00 at: http://feedproxy.google.com/~r/TheCodeDump/~3/IkNchEloXI4/
Speaking: Forthcoming talks
News on a few talks I'll be giving:
- I'm speaking at ACCU 2012 next week. Details of my talks are available here. This year I'm in the "tools" track. Make of that what you will.
- I'm speaking at Mobile East in June, on Advanced iOS Development.
As ever, I promise plenty of fun and interest. And technical content.
By: Pete Goodliffe on: 2012-04-20 08:11:41 at: http://goodliffe.blogspot.com/2012/04/speaking-forthcoming-talks.html
Why is Estimating so Hard?
Consider the Gettysburg Address:
“Four score and seven years ago our fathers brought forth upon this continent a new nation, conceived in liberty and dedicated to the proposition that all men are created equal…”
Let’s ignore the profundity and melody of those remarkable words, and focus instead on the formatting. I’d like to fit the entire address on a bookmark measuring 1.5" X 8". I’ll use a mono-font that fits 10 characters per inch. And I’ll leave 0.1" on the right and left. So I can fit 13 characters across each line. The text contains 237 words. How long do you think it would take you to manually break the address up into 13 character lines, breaking those lines at appropriate spaces?
The calculation isn’t difficult. If you spent one second per word determining whether or not that word is the appropriate break point for a line, it would take you just under five minutes to break the entire address up into lines that are 13 characters or less. And the odds are you’d do it perfectly.
So how long would it take you to write a program to do it?
Now remember, you know this algorithm. You can execute it manually intuitively. During that five minute manual execution there would be no surprises, no stumbling blocks, no backing up and redoing old lines. This is an algorithm that you can execute without even thinking of it as an algorithm. You’d just do it.
So how long would it take you to write a program to do it.
Keep in mind that a program is nothing more than the detailed instructions for following a procedure; and this is a procedure you already know!
I’ll be kind to you. Don’t give me a single estimate. Give me three estimates. Tell me how long it will take in the best case, the worst case, and the nominal case. Go ahead, write these three numbers down. Now.
Got em? OK, now write the program. Make sure it works. I’ll wait here until you are done.
- * * *
Done? How’d you do? Most people need 30-45 minutes to get this working. I’ve seen it done in 15, and I’ve seen it done in 90. Did you fall within your estimate range? Or did you blow the range completely?
Of course lots of people blow the range completely. One of the reasons they blow it is that they estimate it based on how easy the manual task appears to be. You think to yourself: “I could split those lines in 5 minutes by hand, so writing the program ought to be trivial.” We are sadly mistaken.
I remember sitting down with Kent Beck one afternoon to write this algorithm just for fun. I figured it would take us 10-15 minutes. He and I paired on it, test first, for 30 minutes, and got nowhere. Eventually we gave up because we were teaching a class together and actually had to spend time with the students.
But the experience stuck with me. Why was that algorithm so hard – for us – at that particular time? Why was it so hard to write down the procedure for doing something so basic and intuitive?
Answer: Because when we do it manually, we don’t follow a procedure. What we do instead it continuously evaluate the output and adjust it until it’s right. A procedure is blind. It doesn’t look at the output to see if it’s right. If the procedure is wrong, the output will be wrong. Period. But we, humans, are goal seekers. The goal is to split the lines up to no greater than 13 characters, and so we evaluate every line. We look it over and adjust it until it meets the goal. And we can do that in 5 minutes.
It turns out that we don’t know the procedure. We haven’t got any clue to just how difficult the procedure is. We aren’t computers. We don’t follow procedures. And so comparing the complexity of the manual task, to the complexity of the procedure is invalid.
This is one of the reasons that estimates are so hard, and why we get them wrong so often. We look at a task that seems easy and estimate it on that basis, only to find that writing down the procedure is actually quite intricate. We blow the estimate because we estimate the wrong thing.
Try this. Break some long string of text up into columns that are 10 characters long. Each time you break a line, record the position of the break, and why you decided to use that position. If you are good at abstracting, you’ll likely come up with three different scenarios for breaking a line. 1. you break it at the 10th character of a word if that word is longer than 10 characters. 2. You break it at the 11th character if that character is a space. 3. You look backwards from the 10th character looking for a space and if there is one, you break it there.
These three scenarios still need to be arranged into a procedure, but at least you now know how many elements that procedure contains. Knowing that makes the procedure much easier to estimate.
The moral of this story is that tasks that appear easy for a human to solve are often described by complex procedures. So when estimating, make sure you aren’t affected by the apparent ease of that task. Look below the surface to try to enumerate the number of procedural elements.
And if anyone tries to tell you that your estimate is bogus because the task is so simple, ask them to write down the procedure for tying their shoes.
By: uncle bob on: 2012-04-20 00:00:00 at: http://8thlight.github.com/uncle-bob/2012/04/20/Why-Is-Estimating-So-Hard.html
Thursday April 19, 2012
Slides from my MOW2012 Talk
I did talk at MOW2012 about REST and Nancy today. The code in the talk is taking from my port of RestBucks On .NET to Nancy, and here are the slide:
Nancy + rest mow2012View more presentations from Christian Horsdal.
By: Christian Horsdal Gammelgaard on: 2012-04-19 14:25:43 at: http://horsdal.blogspot.com/2012/04/slides-from-my-mow2012-talk.html
Wednesday April 18, 2012
Programming as an Individual Activity
I've decided to come back to Weinberg's classic 'The Psychology of Computer Programming' since it is at the heart of why I took up writing about programming in the first place. At my first job oh so long ago, it was obvious that we were nowhere close to a solution to programming-in-the-large. With applications small enough to be written by a single developer we could manage to deliver software that works, maybe it was inefficient or clunky but it worked well enough. Sure large systems were built using the waterfall approach but they would invariably overrun both their budget and their schedule. The industry was by no means young, even though the PC revolution was in full swing, the underpinnings had already been discussed ad nauseum. You could dismiss the waterfall method but would still be left with the same questions, 'what do they want?', 'how do we build it?', 'how long will it take?', and so forth. The Agile or Lean movements have been able to change the discussion to ask 'what is the smallest amount of work that we need to address at one time' and go from there.
I believe that we have been avoiding the most important questions - which are uncomfortable to contemplate - like, "what is the largest single aspect that controls a software schedule?" or "How do we plan a project when the members of the team are not pluggable resources?"
This brings me back to one of the biggest unresolved question of our field, "Why can't we engineer software like we engineer buildings or spacecraft?" I ask this not for serious comparison since the differences are legion, but rather to point at the single most important advancement in the field of engineering since the advent of the first simple tools (the lever, the wheel, etc), calculus.
Why calculus you ask? because it gives us a way to plan for infinite variability and still have confidence in the result. Planning a trip to the moon would be impossible without being able to calculate how much fuel is needed since how much fuel is needed depends upon the weight of the rocket which creates a recursive dependency.
Software will have no equivalent for calculus because the variability comes from the people participating in the project. Until we accept that people are a first-order component of any software project we will continue to look to silver-bullets, the next development process fad, or the latest new-fangled technology for relief.
By: Kelly on: 2012-04-18 18:28:02 at: http://feedproxy.google.com/~r/TheCodewrightsTale/~3/o1alhvj_1BM/programming-as-individual-activity.html
Pattern Ignorance
I've been in graduate school for a few years now and keep asking myself how we could engender good habits in students - like any good Codewright - during their education, like usage of version control or refactoring.
My database class provides a good example of the potential and the obstacles. The first project involves creating a schema where the tables have contraints that prevent the tables to be created all at once and those same constraints make it impossible to load the sample data all at once. You don't need the actual schema, I'm just describing a bit of complexity where it influences the assignment.
So the data is provided in text files in a comma seperated form and the approach I decided upon is simply parsing the values and then generate SQL statements in the right order. First off, I thought about using an ORM framework, like Hibernate, but have no experience with one. I did find a CSV library to parse the data which cut down the code I had to write but will complicate the grading because the TA will need to download and extract the library in order to run what I submit so I'll have to include those details in a readme file.
So, processing a single file is fairly straightforward; parse the file into a list of lines, loop over the lines, generate the appropriate SQL statement for the data from that file. I soon found myself repeating code for looping over the lines since the files for each table needed slightly different SQL statements. In rejecting the ORM approach, avoiding the definition of domain objects as simple containers for data -- I also didn't really need domain objects for each file because there was not going to be any behaviour, not to mention the lack of a data framework -- I continued the straight text approach. Looping over the lines in the first file (Employee), it was easy to directly call a routine to generate SQL rows. This caused a problem when I wanted to reuse the looping structure for the next file (Departments). I could leave the loop and add an argument but that would require defining an interface and implementing a distinct class for each file. Avoiding data objects puts me on the slippery slope of avoiding other patterns too; what I keep telling myself is it's only for this one project, it's due in two days, and the TA isn't going to give bonus points for using nifty patterns assuming he's ever been exposed to them.
In short, there is no incentive to produce well-written code. The assignment is graded by evaluating the results without regard for the methods used to produce those results.
By: Kelly on: 2012-04-18 17:35:45 at: http://feedproxy.google.com/~r/TheCodewrightsTale/~3/zgEbazQW-Mo/pattern-ignorance.html
apprentice us
Over the past few years I’ve realized that I want to be an active participant in the coming revolution in education. My journey toward this realization has been unexpected and surprising. Over the past 16 years, I’ve worked in group homes of disenfranchised youth, counseled children and families in crisis, mentored high school students, raised my children, wrote a book for apprentices, created a successful apprenticeship program, and helped lead a remarkable community of mentors. Over the past year I’ve been connecting with many kindred spirits such as Dale Stephens and Elizabeth Stark, and through them I can catch glimpses of the revolution ahead.
If I make any contribution to this revolution it will be through my passion for, and my experience with, modern apprenticeships. I am launching what will become a community of apprenticeship program facilitators, mentors, and apprentices at apprentice.us.com. This site will be a place for apprentices to tell their stories, mentors to gain exposure, people to gain insight into how to develop their own self-directed apprenticeships, and learning how to develop formalized apprenticeship programs.
Based on my decade of experience with my own self-constructed apprenticeship in software development, and my observation of dozens of other apprenticeships, I firmly agree with Sir Ken Robinson that, “You cannot predict the outcome of human development, all you can do is create the conditions under which they will begin to flourish.” That eloquently sums up my philosophy on apprenticeship: 90% of apprenticeship is putting someone in the right context, and then getting out of their way. Seriously, stand aside. This is the point where teaching instincts need to be deferred in order to let the learning process proceed naturally in the fertile soil created by strong communities, thoughtful mentoring, cheap or free tools, and open information.
My initial mission for apprentice.us.com is to deliver a message to any person, organization, or company who finds it difficult to hire qualified candidates: There are amazing people who will exceed your expectations if you can adapt your hiring practices to accept less qualified candidates. The simplest first step toward this required adaptation is for people, organizations, and companies to get involved in mentoring outside of their usual social network. Through mentoring and apprenticeship, we have the power to transform the workplace, higher education, and ultimately, our society. My goal for the coming revolution in education is to see a society with a strong emphasis on learning emerge from our outdated emphases on diplomas, grades, and lecture halls.
If you’d like to learn more about this community of people with a passion for decentralized learning, visit apprentice.us.com.
By: on: 2012-04-18 12:12:00 at: http://nuts.redsquirrel.com/post/21321221114
After the Disaster
There’s a disaster coming. I don’t know when. I don’t know what. But it’s coming, and there’s nothing we can do to stop it; but there is something we can do to mitigate it.
How much software is running near you at the moment? Of course you are reading this on a web browser, and that computer you are sitting next to has lots of software running in it. And there are probably many other computers near you with software running on them. Is there software in your cell phone? Of course. How about in your watch? Likely. In the light switch on the wall? How about in the light bulbs? The intercom? The doorbell? The thermostat? Your furnace? Your air conditioner? Your refrigerator, dishwasher, washing-machine, drier? How about your car; and all the other cars on the road? How about the traffic signals? Did you ride an elevator today? Get in a plane or a train? How about an escalator? Do you have a pacemaker? An insulin pump?
When you think about it, it’s everywhere! IT’S EVERYWHERE! And it’s spreading…
How many times per day do you put your life in the hands of an ‘if’ statement written by some twenty-two year old at three in the morning, while strung out on vodka and redbull?
Some time in the not too distant future, there’s going to be an event. Thousands of people will die. And it will be the fault of some errant piece of code written by some poor schmuck under hellish pressure facing impossible deadlines. Perhaps it will be an airline crash, or a cruise ship sinking. Perhaps it’ll be an explosion at a factory, or a train accident involving toxins. Perhaps it’ll be a simple clerical error at a medical research lab that causes a vial of smallpox or ebola to be improperly disposed of.
It doesn’t matter what it is. What is sure is that it’ll come. The probability is not high that it will happen today, or even this year; but the probability is also not zero. It will happen.
And when it happens, when thousands of people are killed by a stupid software error, the governments of the world will act. They’ll have to. The population will scream for protection, and the lawmakers will respond with self-righteous indignation. In their toolkit they’ll have regulations, restrictions, licensing requirements, and certification tests. They might take control of our education. They might specify who can be hired and who can’t.
What tools they bring to bear upon us depends upon us. When the disaster happens, what will the congressional and world court investigations find? Will they find a software industry that has defined a set of professional disciplines that it requires of it’s members? Will they find that the software industry has done the due diligence to ensure that it’s members are educated, trained, and skilled? Will they find that the software industry is composed of serious professionals who reliably follow their disciplines and practices?
Or will they find the chaos that exists today? Will they find developers who don’t write tests? (Can you hear the strutting politicians making hay with that? “Mr. President, it is my sad duty to inform this august body that these developers have no record that they test their code…”) Will they find that developers work at all hours of the day and night, are under hellish pressure and impossible deadlines? Will they find that there are no professional standard, practices, or disciplines. Will they discover that we are all really just a bunch of undisciplined hacks?
The answer to that question will determine which, if any, of those regulatory tools those self-righteous posturing politicians will foist upon us when the accident happens. If they find that we are disciplined, and self regulating, then perhaps they’ll leave us mostly alone. But if they find that we are undisciplined hacks then you know that they’ll impose all manner of horrible regulation upon us.
They might tell us what languages to use. They might tell us what process to use. They might tell us what our working hours must be. They could give us a dress code. They could turn us all into civil servants. They could do anything that want.
We need to get ahead of this one before it happens. Otherwise we’ll work in a government regulated profession. And then life will be hell.
By: uncle bob on: 2012-04-18 00:00:00 at: http://8thlight.github.com/uncle-bob/2012/04/18/After-The-Disaster.html
Monday April 16, 2012
A fresh take on DCI with C++ (with example)
If you'd like to purchase Sol Trader you can now do so at soltrader.net!
I’ve been reading quite a lot about DCI recently, both from the point of view of the original paper published in 2009 and various other sources on the Internet. There’s been a discussion around beginning to use it with Ruby on Rails, but at the moment I’m more interested in how to apply the principles to Sol Trader in C++.
What is DCI?
DCI stands for Data, Context and Interaction. It places behaviour at the forefront of your design by setting the stage for a particular use-case through Context objects, and having all the behaviour exist in Role objects seperate to your basic persisted Data objects. For example, you might have an Account “Data” class, which just contains the data representation and basic methods such as IncrementBalance and DecrementBalance. You’d then have a use-case TransferMoney with two roles: SourceAccount and DestinationAccount. These roles would be played by Account objects, but the behaviour of the objects would depend on the roles they play in the use case. The behaviour of the system is therefore captured in one place: it’s in the interaction between the roles within a particular use case context, rather than being spread all over different data classes.
This design paradigm is very interesting. We’ve known for a while that if you mix persistence and behaviour you’ll get into somewhat of a mess with your code design after a while. What’s new is that whilst we avoid mixing persistence and behaviour, we still often mix data and behaviour: that is, we put code describing what the object does in the same class as the code which describes what it is. This is a subtle violation of the Single Responsibility Principle; I hadn’t noticed this violation before reading about DCI.
The proponents of DCI advocate injecting methods describing the Role in any given use case directly into the data object when setting the use case up. This is easy in a language like Smalltalk or Ruby, but is considerably harder in C++. What approach should we take in C++ with Roles? Is this the right approach at all?
The templating method for injection of role behaviour
One way around this it to use templates: subclass your Data objects with a templated class which includes the roles you want the object to play. For example, to take our account example earlier, we could have:
class DestinationAccount {
public:
virtual ~DestinationAccount() {}
virtual void DepositMoney(int amount) = 0;
};
template <class DataClass> class DestinationAccountCollaborator :
public DataClass, public DestinationAccount
{
DestinationAccountCollaborator(int id) : DataClass(id) {}
virtual void DepositMoney(int amount) {
DataClass::IncrementBalance(amount);
};
};
We would also have a similar set up for SourceAccount. This way we can pass a pointer to the DestinationAccount interface to our Context to set up the use case:
class TransferMoneyContext {
DestinationAccount& _dest;
SourceAccount& _source;
public:
TransferMoneyContext(DestinationAccount& dest,
SourceAccount& source) : _dest(dest), _source(source) {}
};
...
DestinationAccountCollaborator<Account> dest(accountNumberId);
SourceAccountCollaborator<Account> source(sourceAccountId);
TransferMoneyContext context(dest, source);
The DataClass would then instantiate itself from the account id and the role contains the description of the behaviour.
In practice however, I found this extremely unwieldy. My data classes all had slightly different interfaces, especially as many of them served as API endpoints. The templates ended up being ‘clever’ code - they saved very little space at the expense of a good amount of readability. The whole point of DCI is to try and capture behaviour in the Role classes to improve readability and create a cleaner design, and this approach wasn’t serving that purpose. There might be better ways of doing it, and I’d be grateful if you’d let me know if you know of a better approach.
The composition method for roles
The DCI literature teaches us to inject behaviour into the Data objects, to prevent self schizophrenia). For complex use cases, I can see that it would be useful for roles to have access to the methods defined on data objects: but perhaps it would be better to have simpler use cases and have roles only be defined in terms of other roles? In that instance, the roles can simply compose the data objects and expose whichever methods seem appropriate to the other roles in the use case.
A worked example
As an example, consider this use case that came up recently in Sol Trader: I have a MarketListing object which contains a particlar Good (such as Grain, or Water) available at a certain price. The GUI displays a list of these MarketListing objects in a table format. Whenever a change was detected to any of the listings I would clear the table and reconstruct the gui elements, rather than updating the original elements.
This worked fine, until I realised that the GUI library I’m using did not expect GUI elements to be deleted and recreated under the mouse cursor, and wouldn’t fire “click” events correctly at the newly created elements.
Therefore I needed a way to synchronise the GUI table with the MarketListings somehow, add new listings that have appeared, update the text of any existing listings, and remove old elements that refer to listings that no longer exist in the set. I decided to try to implement this using DCI, using the composition approach to roles I’ve discussed.
The use case is quite simple:
- For each source data structure:
- Does it already exist? If so, update the elements
- If not, create new elements
- Remove any elements that weren’t checked this run
After writing some tests, I started with the following context object:
class RowUpdater {
role::TableSource& _source;
role::TableRepresentation& _table;
int _timestamp;
public:
RowUpdater(role::TableSource& source, role::TableRepresentation& table) : _source(source), _table(table), _timestamp(0) {}
void execute();
void checkRow(void const* rowIdentifier);
};
Note the two role objects, TableSource and TableRepresentation. I’ll come back to those later.
execute() and checkRow() were defined like this:
void RowUpdater::execute() {
_timestamp = SDL_GetTicks(); // Could be any unique number
_source.enumerateRows(boost::bind(&RowUpdater::checkRow, this, _1));
_table.removeUncheckedRows(_timestamp);
}
void RowUpdater::checkRow(void const* rowIdentifier) {
if (_table.rowExists(rowIdentifier))
_table.updateRowFor(rowIdentifier, _source, _timestamp);
else
_table.addRowFor(rowIdentifier, _source, _timestamp);
}
(In C++ you can’t easily enumerate, so I used boost::bind to call checkRow() on each row in the _source object.)
This code is beautifully simple, and very close to the pseudo code I wrote earlier.
Implementing TableRepresentation
What does this context require of the roles? Here are the methods needed for TableRepresentation, taken directly from the context above:
bool rowExists(void const* id);
void updateRowFor(void const* id, TableSource const& source, int timestamp);
void addRowFor(void const* id, TableSource const& source, int timestamp);
void removeUncheckedRows(int timestamp);
This object is created with the data it needs to manipulate: in this case a Rocket::Core::Element object. When it needs to update elements, it is passed a TableSource role to give it the relevent data. Here’s some of the code for the addRowFor() method:
void TableRepresentation::addRowFor(void const* id, TableSource const& source, int timestamp) {
Rocket::Core::Element* entry = _element->GetOwnerDocument()->CreateElement("li");
entry->SetAttribute("good", (void*)id);
std::vector<std::string> columnList;
source.fetchColumnList(columnList);
std::vector<std::string>::iterator it = columnList.begin();
for(; it != columnList.end(); it++) {
ChildContentTag(entry, "div", it->c_str(), source.rowFor(it->c_str(), id).c_str());
}
_element->AppendChild(entry);
entry->RemoveReference();
entry->SetAttribute("updated_at", timestamp);
}
There’s a lot of noise here, but note the use of source. The code creates a new li element, gets the column list from the source and then asks the source for the string data for a particular row using rowFor(). The roles are interacting to provide the behaviour of the use case.
Implementing TableSource
TableSource needed to be an interface in the end to manage both viewing a series of MarketListings and also a player Inventory. Here are the methods:
virtual void enumerateRows(boost::function<void(const void*)> action) = 0;
virtual std::string rowFor(std::string const& key, void const* id) const = 0;
virtual void fetchColumnList(std::vector<std::string>& list) const = 0;
For a MarketListing, here’s the implementation of the key methods that the TableRepresentation needs:
void CommodityMarketTableSource::fetchColumnList(std::vector<std::string>& list) const {
list.push_back("name");
list.push_back("price");
list.push_back("quantity");
}
std::string CommodityMarketTableSource::rowFor(std::string const& key, void const* id) const {
MarketListing const* listing = _market.listings()[(Good const*)id];
std::stringstream stream;
if (key == "name")
return listing->name();
if (key == "price") {
stream << "$";
stream << listing->price().amount();
return stream.str();
}
if (key == "quantity") {
stream << listing->amountAtThisPrice();
return stream.str();
}
}
The player Inventory table source code is very similar.
Tying it together
How do I use this thing? Inside my controller for updating the GUI window, I do the following:
void MarketController::syncInventory() {
Rocket::Core::Element* entries = _planetWindow->GetElementById("inventory")->GetLastChild();
gui::role::TableRepresentation tableRole(entries);
gui::role::InventoryTableSource sourceRole(_inventory);
gui::RowUpdater(sourceRole, tableRole).execute();
}
void MarketController::syncMarketListings() {
Rocket::Core::Element* entries = _planetWindow->GetElementById("market")->GetLastChild();
role::TableRepresentation tableRole(entries);
role::CommodityMarketTableSource sourceRole(_market);
gui::RowUpdater(sourceRole, tableRole).execute();
}
In each case the TableRepresentation is the same, with a different target element, and the source is different depending on what I want to show for that table.
In conclusion
I could have simply used a list of MarketListing objects instead of my TableSource, and manipulated the Element objects in the GUI directly. That’s what I did at first, but this approach gives me a number of advantages:
- The code for enumerating rows, and exposing certain data to to the GUI is kept out of
MarketListing, which is great: it only makes sense in this Context which is exactly what a role is for. - The actual guts of the synchronisation code is kept in the Context. I’m not sure this is the best place, but it’s great to have it in one place.
- It was trivial to add a
role::InventoryDataSourceobject: in another 30 minutes or so I had TDDed out the display of inventories of goods using the same Context and slightly different roles. - I could potentially replace the
TableRepresentationwith anything which we need to sync lists of tabular data with.
I tested this using some real CommodityMarket objects, which contain MarketListing objects: I poked new goods into them and checked the elements were being created and removed successfully.
Here’s a screenshot of the market at work:
In summary, I’m very pleased with how this turned out. There is a bit more code than just hard wiring it, but all my behaviour is in one place, and I’ve not loaded my market and goods classes with yet more functionality. I’m now looking for other use cases to implement using a similar method, as I move on to building a realistic (as opposed to random) economy.
How do you like my approach to DCI? Have I missed something profound, or how could I improve my approach?
By: on: 2012-04-16 11:20:48 at: http://feedproxy.google.com/~r/ChrisParsons/~3/hjjnumaPNec/a-fresh-take-on-dci-with-c-plus-plus
Friday April 13, 2012
Weekend Reading
This video documentary is so worthwhile watching. It’s about an game arcade built out of cardboard boxes and packing tape. Great stuff especially when news of Caine’s Arcade hit the ‘front page of the internet’.
And also … You’re on a racing yacht, 650 miles from the finish line of the fifth leg of an around-the-world race. Your mast breaks, you send a team member up to cut free the sail. He slashes at the rigging but also himself, and blood drips down the mast. He comes down white with blood loss and with a massive wound. What do you do?
‘After talking to our team doctor we decided to staple him together. We took out the staple gun and put five staples in him and now he’s as good as new, I think.’
Kiwi’s … they’re a tougher breed!
http://boingboing.net/2012/04/11/yachting-team-uses-staple-gun.html
Interesting links from the interwebs …
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: kane on: 2012-04-13 20:01:26 at: http://feedproxy.google.com/~r/Scrumology/~3/yqRJ6txsRVI/
Craftsmanship Begins With You
What does it take to be a professional?
This week, we held series of events to kick off the launch of the 8th Light Florida offices in Tampa, FL. Our evening event was Uncle Bob Martin giving a talk on Demanding Professionalism in Software Development. At the end, I did a Q and A session with the audience, and one of the questions that came up was "How do I get my organization to care about craftsmanship?"
The context for the person asking was that they were a contractor dealing with a large, very legacy application being handled by a large team embedded in a large company. No tests. No refactoring. Probably lots of spaghetti code with large functions and methods. And it took me back many years to a smaller version of the same question: "How do I convince my boss to let me do TDD?" And the answer was as crystal clear as it was true.
You don't. You just do it.
Being a professional isn't something that you get permission to do. It's something you are. If you want to see craftsmanship and professionalism on your team, you start with you. But what does that mean? What are the qualities that set apart someone we would define as a craftsman? While there is a lot to be said in some great books, and in the craftsmanship manifesto, there are some specific qualities I identify with:
- Hungry - One of the defining characteristics of applicants to 8th Light is their vocation - their hunger to learn. They aren't satisfied with their tools, or their knowledge, or their language. When things don't go right, they think through it, and reflect on it, and find ways to make that better. A similar passion is seen in Entrepreneurs who launch companies. But the same passion can be found inside larger companies - people truly hungry to learn, to grow, and to make themselves and their teams the best they can be.
- Humble - Because of that hunger and that desire to learn, humility is an important characteristic. You can't learn if you have the attitude that you are the expert already, and therefore can't ever be wrong. When mistakes happen, a craftsman works not to blame, but to seek the root cause - even if it was with their code. (See how we handle bugs as an example)
- Practiced - Sustainable growth doesn't come from all night reading sessions. It comes through the practice of the concepts you have, over and over, until they are second nature. So when the next spurt of learning comes in, you're able to retain what you had before, plus begin practicing the new skills. This is done through focused exercises like katas and koans.
Articulate - Because professionals are practiced, they can articulate the code smells they see. For example, is there anything wrong with the following:
def show id = params[:id] @monkey = Monkey.find(id) redirect_to not_found_path if @monkey.nil? if @monkey.banana_pouch.color == :red colorize_screen end endHopefully the answer is yes. But can you articulate why? Things like the The 4 Rules of Simple Design, the SOLID Principles and the Law of Demeter. It's good to be able to start "smelling" bad code - but even better to be able to have a sensitive enough nose to know what those smells are.
- Diversified - Knowing a language is great, but it isn't enough anymore. If you do OO, you should try functional languages. If you use dynamic typing, you should try static typing. If you use a compiled language, try an interpreted one. If you use a relational database, try a document one. Try learning Seven Languages in Seven Weeks or Seven Databases in Seven Weeks.
- Sustainable - There's a lot you can do, and a lot you can learn, but you have to do it at a sustainable pace. This is a lifelong commitment to your craft, and if you let long hours, venomous arguments, and worst of all - bad colleagues - bring you down, then it will be hard to be...
- Passionate - And passion is the best part. I love talking about great teams, and about craftsmanship because of how much of an impact it can have on developers accustomed to the mentality that they are merely resources being used in the cog of some big machine. But there are questions you should be asking yourself and your team (especially if you are a team lead). And when you invest in yourself, and you invest in your team, truly amazing things start to happen.
The important thing is that you define being a professional in terms of who *you* are. It doesn't matter your team, your company or your position. You can change your organization or you can change your organization - but in both of those cases, it starts with not changing who you are - staying true to the value system that defines what you find acceptable. That kind of value system can be infectious. And when it isn't - gives you the confidence to find an organization that values the craft of software.
By: cory foy on: 2012-04-13 00:00:00 at: http://8thlight.github.com/cory-foy/2012/04/13/craftsmanship-begins-with-you.html
Thursday April 12, 2012
Learn a New Language
We're already a quarter into the year. Have you learned a
new language yet?
In Pragmatic Programmer, one of the 70 tips is to invest regularly in your knowledge portfolio. And probably one of the most popular advice is to learn at least one new language every year. So, what language have you learned this year? If you haven't started, don't worry, there's still some time. Here are some tips to get you started.
-
Picking Your Language
Some of you have a personal list of languages you want to learn. Here's my personal list of languages (in alphabetical order):
- Amber
- BiwaScheme
- Clojure
- Dart
- Elixir
- Go
- Mirah
- Objective-C
- OCaml
- Redline Smalltalk
- Rust
- Self
-
Koans
If the language you want to learn has a set of koans, then I highly recommend going through them. Koans are sets of unit tests that exercise the features of the language. The idea, originally by Ara Howard, became popularized when EdgeCase introduced Ruby Koans. From there on out, others have created koans for other languages.
Here is a list of some of them:
If no one has written koans for the language you want to learn, what better way to learn a language than by creating koans? Not only will it be a motivation to learn a language, you will also be contributing to the community by giving others the opportunity to learn the language.
-
Building A Breakable Toy
As described in Apprenticeship Patterns, a breakable toy is a pet project that allows you to learn in a safe environment where you're allowed to make mistakes and fail. Experience builds upon failure and success.
If you prefer to write something other than koans, build a breakable toy. One example would be to write a Tic-Tac-Toe that has an unbeatable computer. Another would be to build a simple HTTP client. Try not to use third-party libraries and instead rely on the standard library that is provided in the language. Push it out to GitHub and let the community see your project.
-
Contributing to Open Source Project
Find an open source project that interests you in the language you want to learn. This gives you an opportunity to read someone else's code, looking at the style and convention. You may also pick up on language patterns that other developers use.
Be careful when choosing a popular project. Popular != quality and may fall short of good practices, patterns, and principles.
-
Pair Programming
Pair with someone who has a deep understanding of the language you want to learn. You can quickly pick up on the idioms and conventions. This may be the quickest way to dive into a new language and it is to your advantage to ask many questions.
I've probably stated the obvious, but hopefully this will kickstart your getting started on learning a new language. As pragmatic programmers, as craftsmen, it's important to keep up to date with current technologies, languages, and environments. Invest in your knowledge portfolio!
Oh, if you haven't already, check out Jason Rudolph's blog post for more inspiration and motivation.
By: steve kim on: 2012-04-12 00:00:00 at: http://8thlight.github.com/steve-kim/2012/04/12/learn-a-new-language.html
Wednesday April 11, 2012
Guest post: What is an Agile Coach
About the Author: George Dinwiddie is an independent software consultant and coach working for [his own business] iDIA Computing. I first “met” George on the notorious Scrum Development email list where I was impressed with his well-reasoned opinions, delivered at a measured pace. In his own words:
I am a software development consultant and coach with over thirty years of experience creating software ranging from small embedded systems to corporate enterprise systems. With a strong interest in lifelong learning, I have pursued more effective ways of creating software at the technical, interpersonal and organizational levels. My specialty is helping teams become more effective while helping them accomplish their current project. I practice consulting, coaching, mentoring, teaching and training.
You should check out more great articles by George on his blog at http://blog.gdinwiddie.com/.
I am a software development consultant and coach with over thirty years of experience creating software ranging from small embedded systems to corporate enterprise systems. With a strong interest in lifelong learning, I have pursued more effective ways of creating software at the technical, interpersonal and organizational levels. My specialty is helping teams become more effective while helping them accomplish their current project. I practice consulting, coaching, mentoring, teaching and training.
You should check out more great articles by George on his blog at http://blog.gdinwiddie.com/.
Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.
I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.
This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.
I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?
This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them.
If the value received and the cost paid are nearly equal, then cost is of critical importance to avoid spending more than the value received. If the value received is an order of magnitude more than the cost paid, then variation in the cost has much less affect on the Return On Investment. This is very similar to the point that Tom DeMarco made in his article “Software Engineering: An Idea Whose Time Has Come and Gone?” [IEEE Software, July/August 2009] “This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects.”
I fear that for many large companies the generic “Agile Coach,” and the Scrum specific “Scrum Master,” has become a term for a person who neither programs nor tests software, who is added to a development team to make it Agile. It’s as if you could sprinkle some pixie dust on your development teams to make them more productive, or whatever advantage they can see in the adoption of Agile.
Is that what “Coach” now means?
I suppose I shouldn’t be so surprised. The meaning of “’instructor/trainer’ is circa 1830 Oxford University slang for a tutor who ‘carries’ a student through an exam” based on the Hungarian word for a carriage. It’s clear that some people have always wanted to hire someone rather than learn to do for themselves.
Certainly there’s value in getting one project done a little more effectively than you might otherwise. If you can hire someone to work full-time on a project and guide the actions the team to improve the effectiveness for the duration, then I expect you’ll get enough marginal value that you might get some ROI. I’m skeptical about accomplishing that with the most cut-rate of coaches, though.
The true value of coaching, however, is to build the capability of the existing team. Rather than making choices for the team, the coach provides guidance about the choices available, perhaps making recommendations, and encouraging them to consider the options and choose their actions. The coach teaches the team about techniques or tools that increase their available choices. The coach offers observations about the team’s activities, and helps the team make it’s own observations and reflect on them. The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis.
There are consultants whose business model includes making the client more dependent on the consultant. That, to me, is not coaching. And that’s not the model of consulting that I choose.
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: kane on: 2012-04-11 20:01:00 at: http://feedproxy.google.com/~r/Scrumology/~3/X13jqlO7ffE/
Tuesday April 10, 2012
Using Binary Search for Debugging
Practically every developer alive has heard about binary search and knows how it can be used for quickly finding something in a sorted array. It’s no surprise given how easy it is to grasp and how amazingly efficient it is. Just think that finding something in an array of 1000 elements only takes 8 checks. That’s magic!
But I keep getting surprised how many of us only think of binary search when facing exactly that problem (finding something in an array) and nowhere else. It’s such a useful tool I thought I’d mention some of the other uses of it I make.
Finding an offending line
When confronted with a chunk of code that does something I don’t want it to and trying to understand which line exactly is causing it I sometimes simply use binary search on the lines themselves. I start with by commenting out half of the lines and seeing if the problem persists. If it is I know it’s in the lines left, otherwise I know it’s in the lines I commented out. Repeat until you find the culprit!
Finding an offending commit
Sometimes the problem is something like “I know it worked 2 weeks ago”. In those cases you can quickly use your version control tool to effectively pinpoint the commit where it stopped working. If you’re lucky enough to be using git you can use the awesome “git bisect” command. By feeding it with a good commit and a bad commit it starts the binary search for you, slowly zooming in on the right commit by asking you whether a certain commit is good or bad. Actually, if you have a fast and easy to run test that can find the problem you can provide bisect with it and it will automatically run it against commits until it finds the right one. This kind of magic is quite rare to find in the wild, but it’s just so much fun I almost want to write bugs that would be found this way.
Finding some edge number
This problem might just be me and my weird use of computers but I quite often need to find the upper bound of some set of numbers. For example say I want to find out how many pages of results some site has for a certain keyword. If it doesn’t tell me how many there are surely I can’t use binary search? Oh yes I can! By using an open-ended variation of binary search we can start searching for the first page that doesn’t exist (Say, by changing the number in http://site.com/p/1 to 2, 4, 8 etc.). Once we get a number that doesn’t have a page (say, 256) we now know the result is somewhere between it and the previous number (128) and can start the regular binary search routine.
I hope this helped you add another cute technique to your arsenal.
You should subscribe to my feed and follow me on twitter!
By: on: 2012-04-10 20:24:00 at: http://feedproxy.google.com/~r/TheCodeDump/~3/dF1PPJA8O1U/
Wednesday April 04, 2012
A few fallacies, for your consideration
Lately I've been fascinated with the idea of logical fallacies, and
especially problems in arguments that may at first glance seem
reasonable.
Now, clearly not every argument is as tidy as in the mathematical world, where we can derive a swath of lemmas and theorems given a few axioms, and rules for moving from one step to the next. But I think most would agree that we would prefer our arguments to be firmly grounded in logic, to the extent possible. [1] So let's take a look at some common problems in reasoning, in the hopes that keeping them in mind (and attempting to avoid them) will allow our conversations to be more meaningful.
Correlation vs. causation
One of the most famous and easily identified fallacies is the mis-assignment of correlation vs. causation. It even has a fancy Latin name: post hoc ergo propter hoc (after this, therefore because of this). The big idea here is that even when two events happen together repeatably (correlation), that's not generally enough evidence to show that one caused the other. The association may belong in reverse, or there may be another event in play that causes them both, or it could just be coincidental.
Examples
- It rains when I get a carwash, so the carwash caused the rain.
- I yelled at the television and my team scored a touchdown, so I caused the touchdown.
- You checked in some code on our project today and my computer crashed, so you broke my computer.
I notice this particularly often in mainstream journalism about scientific studies. Often, the scientists themselves have been careful to either (a) not argue for causation where only correlation exists, or (b) ensure the process and data actually support causation, but it's hard to check that expectation given only a small blurb on the news about what the latest healthy or unhealthy food is, for instance.
Straw man
In programming circles, the straw man fallacy seems to be a common one, both in actual use and in people recognizing it. A straw man involves setting up a weak or distorted version of an argument you're trying to invalidate, and easily knocking it down.
Examples
- You say my car is dirty. But I'm not going to go get a car wash every 3 days - that would be way too much!
- You want to use NoSQL database X on this project? We can't use every crazy fad datastore that pops up!
- Political party A proposes bill #1. Sounds like they want poor people to die in the streets, and that's wrong.
- Political party B proposes bill #2. Sounds like they want the government to control every aspect of people's lives, and that's wrong.
The interesting thing here is that in many cases, the logic following the setup ends up being flawless. The important question to me is: what is being argued against, and what are the premises? Very often, replacing straw man arguments with deep listening and conversation can lead to the discovery that there is actually more agreement than disagreement.
False dichotomy
My personal most-encountered fallacy (and most-wrongly-used myself) is that of the false dichotomy, where the writer asserts or assumes that precisely one of two options may be chosen.
Examples
- You're either with me or you're against me.
- This piece of code is either good or it's bad.
- We can either write unit tests or think hard about our problem.
Certainly there are real-world cases where there are exactly two choices, and exactly one must be chosen, but often there may be a third option, or we may choose both options, or we may ignore the question entirely, etc. [2] Anytime we can correctly say "But those aren't mutually exclusive!", we're looking at a false dichotomy, and considering decisions beyond those suggested by the question might be reasonable.
Finally...
Now, surely by this point you've taken issue with one or more of my examples, and perhaps you even know the name of what I may have implied here: the fallacy fallacy. The idea here is that when someone uses a logical fallacy in their argument, it makes their argument incorrect, but not necessarily their conclusion. So we must be careful not to dismiss an idea out of hand simply because an argument for it is flawed. It seems to me that disproving a conclusion takes significantly more work than finding flaws in an argument. Specifically, it means creating a new argument!
So, when we construct our arguments, whether for or against, let's take care to make our arguments as correct as possible, to strive to recognize and own up to problems when they occur.
[1] In both writing this article and being (quite!) fallible, I fully expect to make missteps, perhaps by falling into a logical fallacy myself. I hope you will grant me the benefit of the doubt and kindly let me know, at colin@8thlight.com.
[2] And, of course, the same idea can be expanded to cover any finite collection of choices, where we must choose one.
By: colin jones on: 2012-04-04 00:00:00 at: http://8thlight.github.com/colin-jones/2012/04/04/a-few-fallacies-for-your-consideration.html
Sunday April 01, 2012
Collaboration 8
In January of 2012, we at LeanDog were honored to host Jurgen Appelo for his first Management 3.0 course in the US. If you've not read Jurgen's book on "Leading Agile Developers, Developing Agile Leaders", I recommend it. The book is full of good advice and simple techniques for improving the way you manage. Among the items Jurgen shares in his class, I was intrigued by The Seven Levels of Authority and his Delegation Poker game.
Delegation 7
Jurgen's Delegation Poker cards were introduced to several members of the LeanDog family at Codemash and conversation ensued. Within a matter of hours, the phrase "Delegation 7" had become a short-hand reference to the cards and the concepts behind them. Delegation 7 seemed a great tool to help us with some of our own challenges. There were a number of items in the Studio and at LeanDog in general that were failing to get forward motion. Everyone had an opinion, but nobody was taking action. As a self-directed team, we had a clear short-coming; plenty of people were steering and nobody was rowing. The leadership team at LeanDog decided to give Delegation 7 a try. We took on a difficult task; running areas of the business. We set up a simple chart: 
Yeah, but…
Who is going to delegate these responsibilities? An individual to assign levels of responsibility wasn't what we needed. We instead needed to agree on our levels of responsibility within each area. So we made a small adjustment to the concept and each of us placed our names on the chart, indicating the level of authority we felt was appropriate given our roles and experience. 
This isn't going to work
We sat back and looked at the board. After a couple of seconds somebody announced, "This isn't going to work." They were right. We had conflicts all over the place. Anywhere one person wants to Tell, Sell, or Consult, we can't also have an Agree. And "Barney" sees himself as a decision maker in all aspects of the business, providing nobody else true autonomy. But we can make it work
We talked through each of the areas and why each of us placed our names in certain columns. After some discussion and adjustments, we came up with a more workable arrangement. 
Collaboration 7
This variation on the technique worked for us quite well. Delegation was not the right word; this was Collaboration. When I introduced the concept in our studio, we called it Delegation 7, but explained it as a collaborative exercise. The phrasing and the chart were incongruent with the explanation of the exercise. Thankfully, Angela Harms took a little time and came up with a variation on the board. We renamed it Collaboration 7. 
And then there were 8
Jon Stahl made an early suggestion (back in the Delegation 7 days) that we add a Joker Card. The joker is intended to be used when somebody violates the agreements. Say, for example, Robin is a 3 (Consult) and everyone else is a 5 (Advise) or further to the right. Robin makes a decision and Barney refuses to abide by it because it is not the call he would have made. Robin would play the joker card; reminding Barney of his commitment to the group. 
We use Collaboration 8 as a regular part of our toolset at LeanDog. From simple tasks to corporate strategy, we use Collaboration 8 as a fast and simple means of identifying who should be involved in the decisions, to create operating agreements, and to make whom is involved in what activities publicly visible.
By: Michael Norton on: 2012-04-01 19:14:06 at: http://www.docondev.com/2012/04/collaboration-8.html
Saturday March 31, 2012
Weekend Reading
I really enjoyed this info graphic showing the rise and fall of online empires. With the exception of AOL, I’ve had an account on every one of these services. The ‘net has changed (and continues to change) very quickly.
Via: CenturyLinkQuote.com
Interesting links from the interwebs …
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: kane on: 2012-03-31 22:50:02 at: http://feedproxy.google.com/~r/Scrumology/~3/j5AvDZDs480/
Migrating to a GitHub Organization
Recently we finally made the move to a GitHub organization. For the past 18 months or so we’ve been using private repositories on our CTO’s personal GitHub account. Having reached the maximum number of allowed collaborators on a personal account, we decided to make the move.
Basically, it wasn’t that big of a deal at all, but since I couldn’t find any writeup describing it I thought I’d throw it here.
When you want to create a new organization, you can either choose to transform your own account into an organization or just create a new one. We opted for creating a new organization for BillGuard in order to avoid causing Raphael an identity crisis.
The steps were amazingly easy:
- Create a new organization.
- Add to its owners whoever needs to be an owner (up till now you had no owner except for the actual account holder).
- Create a team for everyone that needs access to the repositories. We started simple with a team for developers that allows pushing and pulling.
- For each repository that needs to be migrated go to its Admin section, choose “Transfer Ownership” and move it to the new organization.
- Now everywhere you have a migrated repository cloned needs to run this simple command:
git remote set-url origin git@github.com:ORGANIZATION/REPO.git
That’s it! GitHub magically moves the different web hooks, server deploy keys etc. that were configured on the repositories so they keep working.
Some things to note: In case your repositories have been forked, you need to contact GitHub support to change roots as described here. Also, you might need to change repository URL someplace else like your CI servers.
Happy git hacking!
You should subscribe to my feed or follow me on twitter!
By: on: 2012-03-31 14:19:00 at: http://feedproxy.google.com/~r/TheCodeDump/~3/qi5qpfkN86A/
Wednesday March 28, 2012
Guest post: The IT Manager’s Dilemma with Software Debt
About the Author: Chris Sterling is VP of Engineering at AgileEVM.com, an Agile focused project portfolio and release management tool to support business decision-making in the enterprise. Chris is also a Strategic Agile Management and Technical Consultant, Certified Scrum Trainer, and Innovation Games Facilitator. He is author of the book “Managing Software Debt: Building for Inevitable Change” and helps organizations assess, strategize, and help manage their software debt more effectively.
I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.
I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.
The team continues to complain about working with that legacy codebase because it has so much debt. That software debt slows them down in feature delivery and they are wondering if we can push for priority to be put into paying it back some?” asked the ScrumMaster. The IT Development Manager looked distraught about the request. She knew that paying back some of the software debt would be a valuable effort but what would the business say about the priorities? “Tell the team that we’ll start paying back some of the software debt starting in the next release. We must get the current release out the door and a change in priorities won’t allow us to get there.” the IT Development Manager said.
Considering the circumstances I cannot tell an IT manager that this approach is not the right way to go. In many cases the IT manager is not in a position to push for technical priorities even when they will provide value to the business. As teams continue to develop on a system without managing the software debt effectively feature delivery throughput decreases. The following picture shows a team’s feature delivery throughput versus time spent stabilizing each release over time:
There are many reasons for this software debt accrual:
- Pressure of the deadline
- Inexperienced team members
- Specialization
- Over-complication
- Bad design
- etc…
IT management has looked for ways to minimize the effects of software debt. We introduce processes that in theory will reduce software debt but in reality seem not to lessen the effects at all. Tools are introduced that will ease the software development process but we still see similar or potentially new mistakes made by team members. Individual team members are asked to specialize in particular software development disciplines such as Database Administrator (DBA), Quality Assurance (QA), or Business Analysis (BA). Although we do each of these specialized roles more efficiently it seems that the product delivered still is accruing software debt. So what do we do?
It is my experience that teams that adopt agile test and engineering practices within an organization that supports collaboration between business units and development teams are more successful in the containment of software debt. These teams tend to minimize software debt and will at the very least deliver with consistent throughput release after release. In some cases I have seen teams accelerate the velocity of their feature delivery throughput over time. The following figure represents the problem IT managers have in deciding to manage software debt effectively on existing legacy software:
A team will have to slow their current feature delivery significantly in order to get consistent throughput over time. I would suggest that managing the software debt effectively would be the best decision for a business relying on this software. Software is a valuable asset for businesses that can:
- Reduce costs for business processes by automating significant portions
- Provide information to business quickly so they can make better strategic decisions
- Attain market share providing shrink-wrapped software to meet the market’s needs
- Reduce system decay on existing software assets so they can be used into the future
- and much, much more…
Still, given all of these reasons it is difficult to take on software debt in the wild. We must understand that a typical IT manager has many influences on their decision making, as well:
- Business pressures for a set of features on a certain date for a set cost (The Iron Triangle)
- Expectations of feature delivery based on past software releases
- Unreasonable deadlines due to business issues such as lapsing support contracts and executive management promises
- Perception of their organization and how that reflects on their capabilities
- A compensation plan that does not reward managing software assets for future capability
- etc…
Given all of these circumstances I believe that IT managers are making the best decisions possible. How can we help IT management support our organizational software assets effectively and minimize the effects of software debt? What approaches will allow the software delivery teams to manage software debt while delivering essential features? How can business get more involved and increase understanding of this dilemma that will affect the organization’s capabilities over time? I am interested to hear from anybody who reads this. What are your suggestions?
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: kane on: 2012-03-28 20:01:00 at: http://feedproxy.google.com/~r/Scrumology/~3/irf8FvUsbOE/
Using the Implicit Operator in C# for Maximum Nerdy Good Times
My current team works with a lot of data. We represent that data with explicit types. For example if a string represents a Name we create an explicit type called Name like so:
public struct Name
{
private readonly string _string;
public Name(string name){ _string = name; }
public override string ToString() { return _string }
}
This makes things nice for testing purposes as these value structs are comparable for free and are clearly named what the value represents. The downside is if you need to set up a bunch of test data for a unit test you can run into code that looks like this:
Name name = new Name("Name");
IEnumerable<Name> names = new[] { new Name("Tom"), new Name("Dick"), new Name("Harry"), }
This will quickly give you carpal tunnel with all the ceremony required to create all the instances. It would be nice if we could reduce some of the noise and we can via use of the implicit operator. All we need to do is add the following operator logic to our struct.
public struct Name
{
private readonly string _string;
public Name(string name){ _string = name; }
public override string ToString() { return _string }
public static implicit operator Name(string name) { return new Name(name); }
}
What does this buy us? How does the following syntax strike you?
Name name = "Name";
IEnumerable<Name> names = new[] { "Tom", "Dick", "Harry", }
We are used to using implicit typing from on the left hand side of a statement, were you aware that it can be used on the right hand side? I wasn’t. But basically this is how collection initializers work. Nice eh?
Thanks to Robert Ream for showing me this. It was fun working with someone with such a deep understanding of the language and functional development, even if it was a brief time.
By: Bobby Johnson on: 2012-03-28 18:06:22 at: http://feedproxy.google.com/~r/IAmNotMyself/~3/nU4o52RUGgY/
Monday March 26, 2012
What Careless Code Says
There is a certain type of bug that, when it appears as a result
of my code, causes me deep embarrassment.
This type of bug isn't caused by missed or misunderstood acceptance criteria, although those are frustrating for different reasons. Bugs that occur only when the wind is blowing a certain way are irksome, but sometimes can't be helped.
The type of bug I'm referring to are the ones brought by laziness, sloppiness, or a lack of time spent on the feature in the name of getting things done quickly.
When someone finds a bug like this in my code, it is almost always because of a moment of carelessness. At some point I try to rush in order to move on, and I can usually see in the code where it happened - a method doing a little too much, a poorly named class, or messy unit tests that ache for refactoring.
I'm not just upset because it will take me time to fix it, but also because of the groups of people it will affect. My client may be forgiving, but it takes time to test and deploy the fix, and if it happens often enough, it degrades my credibility.
Of course, users are affected as well - software that doesn't behave as expected is software that tends not to be used.
The Effects of Careless Code on a Team
In a team setting, however, what may be the most embarrassing to me is the effect on my team. Time I spend fixing my own bugs detracts from my ability to contribute that week, but that itself hardly compares to having someone else come across my carelessness.
Careless code doesn't just lead to bugs. Code that is poorly designed, unreadable, or untested may not affect clients and users right away, but the team sees it and feels its effects the next time requirements change.
Not only does this type of code cost my team members time, it says that I'm more concerned with getting things done quickly instead of right. The code says that I don't mind if someone else has to spend extra time to clean up after me.
My careless code says that their time is less valuable than mine.
Avoiding Careless Code
My code doesn't mean to say such nasty things. Often when I get careless, I'm frustrated and tired and just want to move on. What I need to do in those situation is to take a break, clear my head, get help if I need it, and sit down to do things right instead of plowing forward.
A great way to avoid carelessness is to pair - I am far less likely to get away with lazy implementations if someone is there to help me out and keep me accountable.
I've worked on many teams where someone is feeling overworked and is trying to get too much done at once. These things happen, and on a good team people will help pick up the slack and move past a single incident. However, if it's a recurring theme, it can cause distrust among the team and generally make everyone's lives more miserable.
If you find yourself in a situation when you're trying to just "get it done", think about the rest of your team. The investment in getting it right the first time will continue to pay dividends over time.
By: mike jansen on: 2012-03-26 00:00:00 at: http://8thlight.github.com/mike-jansen/2012/03/26/what-careless-code-says.html
Friday March 23, 2012
Weekend reading
The following video is a wonderful account of a 9 year old try to be brave on her very first ski jump. It’s quite beautiful for the raw emotions that she shares … uncertainty, fear and ultimately relief and jubilation. It’s a little slow at the start but worth watching all the way through.
Interesting links from the interwebs …
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: kane on: 2012-03-23 20:01:11 at: http://feedproxy.google.com/~r/Scrumology/~3/j6Se1pPh8QA/
Sol Trader: a continuous deployment story
If you'd like to purchase Sol Trader you can now do so at soltrader.net!
Continous Deployment is difficult, time consuming to set up and tends to require a high level of buy in from your stakeholders in order to trust the work that you’re doing.
It’s also one of the best things that could ever happen to your project. It prevents bugs, keeps the whole team on their toes, increases buy in and saves masses of time in the long run.
Sol Trader on windows
For the last few weeks I’ve been working hard on getting Sol Trader building and running on Windows. I bought a brand new low-spec Windows 7 PC for this very purpose, and installed MinGW on it in a blaze of optimism.
Why prioritise Windows? Well, apart from the fact that my artist, Aamar, runs Windows, most of the game playing world out there still seem to be stuck on Windows as a platform, so I decided I had to ensure that it should work earlier rather than later. I figured that the longer I left it, the worse it would be to port over.
Turns out I was so right. Getting the game running on Windows was extremely hard and fiddly to do, even after only a few weeks development. I’ll post my specific experiences writing a cross-platform Rakefile and dealing with all the path issues another time.
After the game finally ran, my first thought was: ”I’m never doing that again.” If I leave the codebase to diverge again, who knows how hard it will be when it’s three times the size with twice as many library dependencies.
What I really want to happen is whenever I push new code it’s all checked on Windows to make sure that it compiles and runs without warnings or errors, and runs all the tests to ensure that my code never diverges again…
Jenkins
Enter Jenkins. Jenkins is the world’s most fabulous build system. There are many out there, but I keep returning to Jenkins as the most powerful and flexible. Plus, it’s Java, so it easily runs on Windows, so I can simply install it on the same Windows machine for now.
Most importantly for me, it can build using slave computers, so I installed it and set up my Windows machine as a headless slave using Java Web Start. That was thankfully pretty easy to do, once I’d figured out how to set up the build command so it called the right command. It’s extremely easy to set Jenkins up to check for the latest pushed code and run a new build for me.
Packaging
I have a fairly simple rake task which packages up my app in a windows ZIP:
task :dist => [exe] do
rev = "sol-#{VERSION}-#{fetch('git rev-parse HEAD')[0, 7]}"
if windows?
sh "cp /mingw/msys/1.0/local/bin/SDL2.dll ."
sh "cp /mingw/msys/1.0/local/bin/libfreetype-6.dll ."
sh "cp /mingw/msys/1.0/local/bin/libRocketCore*.dll ."
sh "cp /mingw/msys/1.0/local/bin/libRocketControl*.dll ."
sh "cp /mingw/bin/SDL2_image.dll ."
sh "cp /mingw/bin/libz-1.dll ."
sh "cp /mingw/bin/libgcc_s_dw2-1.dll ."
sh "cp /mingw/bin/libstdc++-6.dll ."
sh "zip -or #{rev}.zip data shaders media #{exe}.exe *.dll"
sh "mv #{rev}.zip /c/dropbox/sol/builds/"
end
end
This dumps a ZIP file containing all the different DLLs plus the executable and assets into Dropbox for Aamar to pick up. They’re helpfully named after the latest commit (the latest one is sol-0.1-0ead098.zip) so Aamar and I can refer to them easily.
Now when I push the code, I only have to wait a few minutes and Dropbox informs me of a new build available. Bliss.
Next steps
- I’ve an iMac at home which we use as a family PC, but they have SSH, right? There’s nothing to stop me utilising that as my slave machine for building OSX builds automatically. Jenkins allows you to build multiple configurations at the same time, so soon there will be an OSX application appearing alongside the Windows ZIP. Just don’t tell my son when he’s playing Minecraft…
- I’d like to run the game for 100 frames or so just to ensure that it’s starting, allocating all its memory and exiting cleanly without memory leaks.
- Valgrind support would be fantastic to check for leaks.
- A screenshot showing the running game to double triple check it would be a great addition. There’s a Jenkins plugin for this, which I’ve not tried yet.
This is all important infrastructure getting ready for a beta release. Putting in the effort now makes the job of releasing new builds so much easier when the pressure is on and I’m trying to get bugfixes out to multiple platforms.
What do you think of the system so far? Any improvements I could make?
By: on: 2012-03-23 12:13:27 at: http://feedproxy.google.com/~r/ChrisParsons/~3/6Zh5oelw0eM/sol-trader-continuous-deployment
Tuesday March 20, 2012
PowerShell, msysgit 1.7.9 and Permission denied (publickey) Errors
TLDR: Add “$env:home = resolve-path ~” to your PowerShell profile.
I recently updated my work Virtual Machine to the latest release of msysgit 1.7.9 to resolve some issues I was having with global settings not being obeyed. After the installation I noticed that I was no longer able to update repositories from PowerShell. The output I was getting looked something like this:
GIT [dirkdiggler] on [master] (clean) | C:\projects\foo -> git pull Permission denied (publickey). fatal: The remote end hung up unexpectedly
This was unexpected and the first thing I thought of was the recent security issue with GitHub, and maybe my work key needed to be validated. I checked GitHub and everything seemed to be set up correctly. I even went so far as to generate new keys with no success.
Next up, it occurred to me to try connecting via git bash.
dirkdiggler@DIRKDIGGLER-VM /c/projects/foo (master) $ ssh git@github.com Hi dirkdiggler! You've successfully authenticated, but GitHub does not provide shell access. Connection to github.com closed.
Bash seems to be working fine. I then started troubleshooting my connection from PowerShell. I tried testing ssh first with the following command.
GIT [dirkdiggler] on [master] (clean) | C:\projects\foo -> ssh git@github.com Permission denied (publickey).
So it looks like the problem was not with git but with establishing an ssh connection to GitHub. I wanted to see exactly what was happening when trying to connect via ssh, so I ran the following command with enables verbose logging of the connection.
GIT [dirkdiggler] on [master] (clean) | C:\projects\foo -> <b>ssh -v git@github.com</b> OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Connecting to github.com [207.97.227.239] port 22. debug1: Connection established. debug1: identity file /.ssh/identity type -1 debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2 debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'github.com' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/identity debug1: Trying private key: /.ssh/id_rsa debug1: Trying private key: /.ssh/id_dsa debug1: No more authentication methods to try. Permission denied (publickey).
This output did not give me any immediate ideas on the problem but I thought I might try the same command from git bash. I won’t include the full output here, but I did notice something different right away. Check out the following lines from the output. Compare them to lines 6-8 above.
debug1: identity file /c/Users/MGALFAPAIR/.ssh/identity type -1 debug1: identity file /c/Users/MGALFAPAIR/.ssh/id_rsa type 1 debug1: identity file /c/Users/MGALFAPAIR/.ssh/id_dsa type -1
So it looks like ssh running under PowerShell is looking for my public/private key pair in a different directory than under bash. Doing a quick google search I found that an environment variable named home is used when determining the path to look for keys. I went back to PowerShell and checked for the environment variable like so.
GIT [dirkdiggler] on [master] (clean) | C:\projects\foo -> Write-Host $env:home
No home variable set. So I set it like so.
GIT [dirkdiggler] on [master] (clean) | C:\projects\foo -> $env:home = Resolve-Path ~ GIT [dirkdiggler] on [master] (clean) | C:\projects\foo -> Write-Host $env:home C:\Users\MGALFAPAIR
Running the ssh test again, I am now able to connect. Adding the command to my PowerShell profile sets it automatically every time I start PowerShell resolving the problem completely.
By: Bobby Johnson on: 2012-03-20 14:51:38 at: http://feedproxy.google.com/~r/IAmNotMyself/~3/4HKpuJ_xj0w/
Monday March 19, 2012
How to Run a Great Conference
I attended CocoaConf on March 16th and 17th. It was one of the best conferences I’ve attended in a long time. Here are some things you can do to make your next conference as good as CocoaConf.
Content
In real estate, the mantra is “location, location, location.” At a technical conference, it’s “content, content, content.” CocoaConf delivered.
My first and favorite talk was “UI Automation” by Jonathan Penn. It was an introduction and guide to using UI Automation, a library to test iOS apps via their UI. Scripts are written in JavaScript. Yes, JavaScript. While everything you need is there, the code can be tedious and low-level. Enter tuneup_js. It adds some extensions to make your scripts feel more like a suite of tests. Check out Cocoa Manifest for slides and more.
I also attended talks by the likes of Daniel Steinberg (Storyboards), Bill Dudney (Documents on iOS 5, Drawing with Core Graphics on iOS), Chris Adamson (Reverse Q&A moderator) and Jeff Bigus (Blocks). These and other sessions I attended were top-notch.
Internet
CocoaConf was held at the Holiday Inn Elk Grove Village. The wi-fi was outstanding. It may have been the best I’ve ever experienced at a conference. Whether using my MacBook Pro or my iPhone, whether in a session, the hallways or the lobby, no matter the time of day, it was FAST!
Feedback
Feedback is essential for the speakers and organizers to adapt to their audiences. How, then, do they obtain this necessity? Make it easy for attendees to give it and offer prizes in return!
In my welcome pack, I found ten review forms, ten being the number of talks I could attend during the three-track, two-day event. The forms were simple and took less than a minute to complete.
For each one I completed, I received a Cocoa Buck with which I could “buy” an entry in the prize drawings to be held at the end of the conference. Ten minutes of my time for ten entries to win a prize. The organizers incentivized feedback in a simple way and made it near effortless for me to share it.
Experiment
In addition to incorporating feedback to improve your talk or conference, you have to be willing to experiment. CocoaConf did just that with its reverse Q&A panel. In the organizers’ words,
“Borrowing an idea from the Penny Arcade Expo (PAX) and the panels held there by Harmonix (makers of the ‘Rock Band’ games), a ‘Reverse Q&A’ literally turns the tables on the traditional panel. Speakers become questioners, and attendees are the ones with the answers.”
The entire audience was engaged in the discussions that grew from the questions asked by the moderator and the panel members. This experiment was a success. I expect the format to be used at future CocoaConfs.
Great People
Time after time, I saw the hotel reception desk worker serve guests extremely well. Also, I heard one guest ask to leave a generous tip for the person who cleaned her room; the person had done a wonderful job.
CocoaConf provided dinner. Since I was fasting until sunset, I asked if I could set aside a plate of food until I was ready to eat. The catering manager and the head chef decided instead to let me place an order later in the evening for anything that attendees were given. They didn’t want me to eat cold food. Wow!
I want to give special recognition to Dave Klein, the organizer, and his family. They were welcoming, kind and helpful every time I interacted with them or saw others doing so. CocoaConf wouldn’t have been nearly as good without people like the Klein family running the show. Thank you.
Your Next Great Event
If you’re a conference organizer or a worker at a venue, emulate CocoaConf. If you’re an attendee, find a conference like CocoaConf. You’ll be very happy that you did.
By: craig demyanovich on: 2012-03-19 00:00:00 at: http://8thlight.github.com/craig-demyanovich/2012/03/19/great-conference.html
Friday March 16, 2012
More Lessons From Outside The Field
Found another interesting parallel between software development and running. The field of running and exercise is full of lots of claims about special ideas that will drastically improve performance of athletes. The Science of Sport site has a blog post on How to spot bad science and fads- Determining whether an idea is worthwhile
At a recent track meet I was having a conversation with a friend in college, who made the astute observation that if the coaches inserted random scientific terms to explain things, even if they were totally wrong, the runners seemed to buy into it more enthusiastically. That’s a very common reaction, we all do it. We associate science and complexity with being smart or correct. As I’ve said before…people trying to fool you go from simple to complex…good coaches translate complex things into simple understandable ideas.
In another post the same site talks about the value of research, theory and practice
… I often rely on what one of my Professor’s, Jason Winchester, called the three stool leg test. You have research, theory, and practice. If you have all three, it’s almost certainly a good idea to implement it. If you have 2 of 3, it’s fairly likely that it works and it depends on the strength of the 2. If you’ve only got 1 of 3 going for it, it probably doesn’t work. The beauty of using the 3 stool leg test is it blends science and practice, and compliments it with theory which in itself is a blend of science and practice.
By: on: 2012-03-16 23:53:00 at: http://www.improvingwetware.com/2012/03/16/more-lessons-from-outside-the-field
Weekend Reading 03/17/2012
There’s lots of interesting news this weekend but let’s start in the right way … If you haven’t seen this video of a downhill bike race in Valparaiso, Chile you really should spend a few minutes watching it. Fantastic and scary at the same time!
Interesting links from the interwebs …
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!
By: kane on: 2012-03-16 21:18:22 at: http://feedproxy.google.com/~r/Scrumology/~3/dWWL4bAp2sI/
Wednesday March 14, 2012
Guest post: Managing Software Debt
About the Author: Chris Sterling is VP of Engineering at AgileEVM.com, an Agile focused project portfolio and release management tool to support business decision-making in the enterprise. Chris is also a Strategic Agile Management and Technical Consultant, Certified Scrum Trainer, and Innovation Games Facilitator. He is author of the book “Managing Software Debt: Building for Inevitable Change” and helps organizations assess, strategize, and help manage their software debt more effectively.
I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.
I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.
Managing Software Debt
Continued Delivery of High Values as Systems Age
Many software developers have to deal with legacy code at some point during their careers. Seemingly simple changes are turned into frustrating endeavors. Code that is hard to read and unnecessarily complex. Test scripts and requirements are lacking, and at the same time are out of sync with the existing system. The build is cryptic, minimally sufficient, and difficult to successfully configure and execute. It is almost impossible to find the proper place to make a requested change without breaking unexpected portions of the application. The people who originally worked on the application are long gone.
How did the software get like this? It is almost certain the people who developed this application did not intend to create such a mess. The following article will explore the multitude of factors involved in the development of software with debt.
What Contributes to Software Debt?
Software debt accumulates when focus remains on immediate completion while neglecting changeability of the system over time. The accumulation of debt does not impact software delivery immediately, and may even create a sense of increased feature delivery. Business’ responds well to the pace of delivered functionality and the illusion of earlier returns on investment. Team members may complain about the quality of delivered functionality while debt is accumulating, but do not force the issue due to enthusiastic acceptance and false expectations they have set with the business. Debt usually shows itself when the team works on stabilizing the software functionality later in the release cycle. Integration, testing, and bug fixing is unpredictable and does not get resolved adequately before the release.
The following sources constitute what I call software debt:
- Technical Debt[1]: those things that you choose not to do now and will impede future development if left undone
- Quality Debt: diminishing ability to verify functional and technical quality of entire system
- Configuration Management Debt: integration and release management become more risky, complex, and error-prone
- Design Debt: cost of adding average sized features is increasing to more than writing from scratch
- Platform Experience Debt: availability and cost of people to work on system features are becoming limited
Software Debt Creeps In
Figure 1.1: A relatively new system with little debt accrued.
Figure 1.1 displays a system that has minimal amount of software debt accrued. A few low priority defects have been logged against the system and the build process may involve some manual configuration. The debt is not enough to significantly prolong implementation of upcoming features.
Business owners expect a sustained pace of feature development and the team attempts to combine both features and bugs into daily activities, which accelerates the accrual of debt. Software debt is accruing faster than it is being removed. This may become apparent with an increase in the number of issues logged against the system.
Figure 1.2: An aging software system slowly incurs significant debt in multiple functional areas.
As a system ages, small increments of software debt are allowed to stay so the team can sustain their velocity of feature delivery. The team may be complaining about insufficient time to fix defects. Figure 1.2 shows a system that has incurred software debt across all functional areas and components.
At this point, delivery slows down noticeably. The team asks for more resources to maintain their delivery momentum, which will increase the costs of delivery without increasing the value delivered. Return on investment (ROI) is affected negatively, and management attempts to minimize this by not adding as many resources as the team asks for, if any.
Even if business owners covered the costs of extra resources, it would only reduce the rate of debt accrual and not the overall software debt in the system. Feature development by the team produced artifacts, code, and tests that complicate software debt removal. The cost of fixing the software debt increases exponentially as the system ages and the code-base grows.
Figure 1.3: The aging system has accrued significant debt in all functional areas and components.
Software debt in the system continues to accrue over time, as shown in figure 1.3. At this point, new feature implementation is affected significantly. Business owners may start to reduce feature development and put the system into “maintenance” mode. These systems usually stay in use until business users complain that the system no longer meets their needs.
Managing Software Debt
There are no magic potions for managing software debt. Software can accrue debt through unforeseen circumstances and shortsighted planning. There are some basic principles that help minimize software debt over the lifespan of the product:
- Maintain one list of work
- Emphasize quality
- Evolve tools and infrastructure continually
- Always improve system design
- Share knowledge across the organization
- And most importantly, hire the right people to work on your software!
Maintain One List of Work
One certain way to increase software debt is to have multiple lists of work. Clear direction is difficult to maintain with separate lists of defects, desired features, and technical infrastructure enhancements. Which list should a team member choose from? If the bug tracker includes high priority bugs, it seems like an obvious choice. However, influential stakeholders want new features so they can show progress to their management and customers. Also, if organizations don’t enhance their technical infrastructure, future software delivery will be affected.
Deployed software considered valuable to its users is a business asset, and modifications to a business asset should be driven from business needs. Bugs, features, and infrastructure desires for software should be prioritized together on one list. Focus on one prioritized list of work will minimize confusion on direction of product and context-switching of team members.
Emphasize Quality
An emphasis on quality is not only the prevention, detection, and fixing of defects. It also includes the ability of software to incorporate change as it ages at all levels. An example is the ability of a Web application to scale. Added traffic to the web site makes performance sluggish, and becomes a high priority feature request. Failed attempts to scale the application result in a realization that the system’s design is insufficient to meet the new request. Inability of the application to adapt to new needs may hinder future plans.
Evolve Tools and Infrastructure Continually
Ignoring the potential for incremental improvements in existing software assets leads to the assets becoming liabilities. Maintenance efforts in most organizations lack budget and necessary attention. The International Organization for Standardization (ISO) standardizes on four basic categories of software maintenance in ISO/IEC 14764[2]:
- Corrective maintenance – Reactive modification of a software product performed after delivery to correct discovered problems
- Adaptive maintenance – Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment
- Perfective maintenance – Modification of a software product after delivery to improve performance or maintainability
- Preventive maintenance – Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults
Most maintenance efforts seek to prolong the life of the system rather than increase its maintainability. Maintenance efforts tend to be reactive to end user requests while business evolves and the technology decays.
To prevent this, attention must be given to all four categories of software maintenance. Budgets for software projects frequently ignore costs for adaptive, perfective, and preventive maintenance. Understanding that corrective maintenance is only part of the full maintenance picture can help an organization manage their software assets over it’s lifespan.
Improve System Design Always
Manage visibility of system design issues with the entire team. Create a common etiquette regarding modification of system design attributes. Support the survival of good system design through supportive mentoring, proactive system evolution thinking, and listening to team member ideas. In the end, a whole team being thoughtful of system design issues throughout development will be more effective than an individual driving it top down.
Share Knowledge Across the Organization
On some software systems there is a single person in the organization who owned development for 5 years or more. Some of these developers may find opportunities to join other companies or are getting close to retirement. The amount of risk these organizations bear due to lack of sharing knowledge on these systems is substantial.
Although that situation may be an extreme case of knowledge silos, a more prevalent occurrence in IT organizations is specialization. Many specialized roles have emerged in the software industry for skills such as usability, data management, and configuration management. The people in these roles are referred to as “shared resources” because they use their specialized skills with multiple teams.
Agile software development teams inherit team members with specialized roles, which initially is a hindrance to the team’s self-organization around the work priorities. Teams who adhere to agile software development values and principles begin to share specialized knowledge across the team, which allows teams to be more flexible in developing software based on priorities set by business. Sharing knowledge also reduces the risk of critical work stoppage from unavailable team members who are temporarily on leave.
Hire the Right People!
It is important to have the team involved in the hiring process for potential team members. Teams will provide the most relevant skills they are looking for, thus, allowing them to review and edit the job description is essential. Traditional interview sessions that smother candidates with difficult questions are insufficient in determining if the candidate will be a great fit. Augmenting the interview questions with a process for working with the candidate during a 1 to 2 hour session involving multiple team members in a real-world situation adds significant value to the interview process. Before hiring a candidate, teams members should be unanimous in the decision. This will increase the rate of success for incorporation of a new team member since the team is accepting of their addition.
Another significant hiring focus for organizations and teams is placing more emphasis on soft skills than technical expertise. I am not advocating ignoring technical experience. However, it is critical in an agile software development organization or team to have people who can collaborate and communicate effectively. Soft skills are more difficult to learn than most technical skills. Look for people who have alignment with the hiring team’s values and culture.
In Summary
As systems age they can become more difficult to work with. Software assets become liabilities when software debt creeps into systems through technical debt, quality debt, configuration management debt, design debt, and platform experience debt.
Applying the six principles in this article will lead to small changes that over time will add up to significant positive change for teams and organizations. The goal of managing software debt is to optimize the value of software assets for our business and increase the satisfaction of our customers in the resulting software they use.
References
- Ward Cunningham – “Technical Debt” – http://c2.com/cgi/wiki?TechnicalDebt
- “ISO/IEC 14764: Software Engineering — Software Life Cycle Processes — Maintenance” – International Organization for Standardization (ISO), revised 2006
Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.
When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!