Archive
Communication is harder than you think
Communication, what does that really mean? Conveying ideas, opinions, directions to another person. That sounds like a good starting point to me. Two people talking to each other, or is it? Communication has been possible in many forms throughout history. Cavemen writing on cave walls, lighting fires on watch towers to send a danger signal faster than any enemy could travel, music, and finally the written word. All of these serve a single purpose, to transfer a message to another person. Other differences can be identified between transfers that occur on a one to one format, and others that occur in a one to many format.
New forms of communication spring up every day, but none of them serve any kind of new purpose. They all fulfill the same function, just in a new way. Blogs are a one to many form of communication, just like newspapers or the pictures on a cave wall. They intend to take the thoughts of one person and make them available for others. New technology simply broadens the audience and shortens the delivery time. Email is a letter that you can send without the latency of the post office, and with the added ability of being able to send to multiple recipients.
So with all these advances in technology giving us newer and newer forms of communication, why is it still so hard? Why do people still so often misunderstand what we are trying to say? It would seem that as communication gets easier, understanding what is meant gets harder. Why is that?
Perhaps as the cost of communication approaches zero, so does our respect for it. For example sending a telegraph in the early 1900′s was not easy and probably not cheap. When somebody wanted to send one, I would presume they would put quite a lot of thought in to the words they used because they were doing something important. Specifically, they would not be taking what they were doing for granted.
Today, it’s quite easy to take communication for granted. If I want to send an email to another person, I don’t think twice about it. I just quickly type out what I want to say and fire it off at little or no cost to me personally. This blog post itself is being made at little cost to myself, although with more thought being put in than the average email would receive.
So why do we take easy forms of communication for granted? It could simply be a matter of quantity over quality. With the amount of communication we have to deal with every day, we simply don’t have time to give each individual communication event during our day as much attention as we’d like to. Imagine how much time it would take if you put enough thought in to each communication you had every day to carefully pick your words and do everything you could to ensure your message was transmitted clearly. My guess is you wouldn’t have time for anything else.
What can you do to help mitigate these issues? The first thing you need to realize is that “perception is reality”. It doesn’t matter what message you intend to convey, the only thing that matters is what message is received. If you realize that, you are well on your way to improving your communication skills. It is important to think about how others are going to interpret what you are saying. There are a few things you can do that aren’t very hard. Firstly try to focus on quality instead of quantity. Pick the most important communications to participate in and make sure you take the time to think about what you are saying with special attention paid to what the receiving parties will be likely to interpret it as. Second, prefer methods of expression that include multiple simultaneous messages. When you send an email, you are sending only a single message, the message contained in the words. When you talk to a person face to face, you are sending the message in the words as well as the message included in your tone, body language, volume, etc. The more streams you can send your message in, the less likely the message will be interpreted incorrectly.
The next time you are communicating with somebody, think about the message you’re sending, and do what you can to make sure it is received as you intended it. You might be surprised how big of a difference it will make.
I welcome any discussion on this topic as it’s of great interest to me, and one that doesn’t get nearly enough attention.
By: Chris Dagenais
Mmmm Breakfast
Today our morning energy level was given a boost by our Customer Service Representative (CSR) team. Not only did they manage to organize “pyjama day” as part of this they also cooked breakfast for the whole company. Waffles, fruit, juice, chocolate milk, whipped cream, sausage and most importantly BACON was provided. Gluttony for all.
Gestures like these are always a benefit to the team as a whole. Many staff get right into the dress up aspect of the day and breakfast is always a good excuse to talk about the upcoming day.
We often do things up here; Hawaii day, crazy hair day, etc. I know it’s cheesy but mixing it up at work to me is always a motivator.
By: James Townley
BCIT Career Fair
Today Joel and I spent the day in Vancouver at the BCIT Career Fair.
“We don’t hire smart people so we can tell them how to do their job, we hire smart people so they can tell us what the best way is to get the job done .”
That was my catch line that I came up with this morning for describing Point2’s development philosophy relating to Agile. It seems like a punchy and yet very accurate way to describe how things work at Point2. It invariably was followed by some chuckling after the first half, and then a look of intense interest after the last half.
The BCIT career fair is a fairly large event with 115 companies participating from a wide variety of fields ranging everywhere from healthcare providers, RCMP, to IT and Software Development.
We got out booth set up this morning which was fairly considerable to many of the other larger companies that were attending the event.
BCIT Booth
The first half hour or so of the event was reasonable with a person coming by to talk to us every couple minutes. It turns out that there are a few fairly specific IT type courses at BCIT, and some of them matched up great with the requirements for our systems administrator positions we’re currently advertising for. By the time the career fair had been going for an hour we were flooded by a constant deluge of students from these programs asking us “hey are you the IT guys so and so told us about?!”. We literally had a line up of people waiting to talk to us for the entire day. Whenever we finished talking to one person, 2 more were in line waiting.
So what did we learn by attending this career fair? A few things stand out for me as quite obvious:
- Even in Vancouver competing with Vancouver IT companies, our company is set apart from the competition because of our development practices. Agile and XP practices are very attractive to young developers and the fun relaxed atmosphere of our company helps a lot as well.
- Even though Agile and XP are nothing new, most people in school still haven’t heard of them, however once explained to them, they love the concept and want to be part of a company that uses them.
- Most people still have not heard of pair programming or TDD.
Most people love the idea of pair programming, especially when combined with Scrum team practices. - There are FAR more specific programs available with regards to systems administration and web development than there were when I went to school. There are courses that teach web development that cover java, C#, ajax, asp.net, css, webservices etc etc. Nothing like that existed 10 years ago. It’s great to see.
- The market for jobs in Vancouver is getting dry. We had many people talk to us who didn’t care where they had to move to find work, they just wanted work.
- There were way more women than I expected showing interest in both the systems administrator role and the software developer roles. I’m interviewing two women tomorrow for positions that both seem promising.
- Moving to Saskatoon is not as hard of a sell as we thought it would be. I would say that about 10% rejected the idea outright, 40% were open to it but not sure, and 50% said it was no problem and they would move to wherever they could find a good job at a good company. The guy running the booth across from us said that we should be on the City of Saskatoon payroll for all the recruiting we were doing for the city, are you listening Don Atchinson?
Those are just off the top of my head. There are other thoughts i’ll be able to put together later once i have more time to think about it.
So programs from BCIT, I can’t believe how many are available. CSIT seemed to be the most common one from the people we talked to. It turned out that our job description for a System Administrator pretty much matched line for line the curriculum for their course so most of those students were quite excited. You’ll have to look for yourself at the wide variety of things offered as the list is quite extensive. BCIT Computer Courses Offered
Tomorrow will be another exhausting day. I managed to line up 7 interviews for developers tomorrow that i’ll be conducting in our Vancouver office. Joel has 4 interviews for sysadmins as well. It’s obvious to both of us that there’s a lot of talent in Vancouver, we just need to move some of it east Opening a Vancouver development office is starting to look more and more attractive…. maybe some day.
By: Chris Dagenais
DevWeek 2009
I’m at DevWeek 2009 this week. I’d hoped to Twitter in real time at the conference, but the wireless internet there is overloaded. I’ve stepped out to a local coffee shop to get online, so my updates will likely be in batches.
The keynote was about cloud computing, and it raised a lot of interesting questions for me. Probably enough material for a decent blog post which I’ll write up tonight in the hotel.
If you’re at the conference, comment here or on Twitter and I’ll try to hook up with you.
By: Aidan
Focused Practice
We all want to be better at what we do, right? But how do we go about improving our skills? I think the answer is the same, whether you’re an aspiring software developer, musician, martial artist, or whatever. The key is focused practice. You need to put time into developing your skill. You can’t just put time in either. It has to be focused time. This is time where you’re consciously thinking about your craft, critically analyzing your work, and looking for ways to improve it.
Some of this possible during your day-to-day life; but in my experience, you always get better results by setting aside a special block of time to work on a skill.
Code Katas
The best way I’ve found to apply this to software is through code katas. A code kata is a problem simple enough that developers of any skill-level should be able to solve them. A kata is also small enough to solve in a reasonable period of time. My learning process currently goes something like this.
- Pick a skill I want to improve at.
- Pick a kata to solve, and a language to solve it in.
- Solve the kata while focusing on how to apply that skill to the kata.
For example, let’s say I wanted to work on my TDD-fu. I would pick a kata that I knew reasonably well; in my case that’s the bowling problem. I would pick a language that I knew well, and had a good testing framework; that would be java and junit. I would then implement a solution while thinking about things like…
- How much code am I writing per test? Should I be writing more? Less?
- Is my test naming clear?
- Am I remembering to think about refactoring every time I see a green bar?
- Am I aware enough of what’s going on to know when I’ve made a mistake and chosen a bad test?
You can use code katas to improve your skills with just about any technique related to software development. Just to name a few, they work well for improving your pairing practices, new languages, writing good OO code, and learning new tools. You just have to pick a focus.
A Coding Dojo
There’s been lots of success stories recently about coding dojos. A dojo gives us a social context in which to work on our katas with other like-minded people. It’s a great mechanism to get feedback on your work, but the downside I’ve found is that a lot of people are intimidated by this. I think the best way to deal with it is just to work on a kata in your own time until you’re comfortable with it, and then bite the bullet and seek some feedback.
You can find more information about code katas and dojos at http://codingdojo.org. See the kata catalogue if you just want to get started. There is another list of problems I’ve found useful here.
By: Kevin Baribeau
Hard Problems
I ran into a hard problem today at work. Here it is:
Given two strings, check that the first does not contain a sequence of 3 consecutive letters that are also contained in the second.
Look easy? It should. I don’t know of very many easier problems. After implementing it though, I can’t truthfully say that it was easy for me. But, I don’t think the lessons I learned today are easy either. As far as I can tell, I made three mistakes:
Lesson #1: Be careful when picking your test cases
It’s easy to pick a test case that’s either too hard, or too easy to implement. If you pick a test case that’s too easy, you and your pair risk getting bored. Oddly enough, this is almost never a problem unless you’re actively trying to avoid picking a test case that’s too hard.
So, if you’re bored, then your tests are too easy… how do you tell when your tests are too hard? Well, that’s another hard problem. I don’t think I’ve nailed this down completely yet, but here are some clues I’ve learned to spot:
- It takes more than one try to get your newest test to pass
- When you do get your test to pass, another test fails
- Your pair doesn’t understand what you just did
- You find yourself wanting to refactor against a red bar
My advice when you run into any of these indicators is to stop. Stop writing code. Revert to a green bar. Now you have two options: Refactor, to make things easier; or pick a different test.
Sound easy? Try it. There’s two reason why it’s not.
First it’s hard to admit when you’ve picked a test case that’s too hard to implement. We’re programmers (craftsmen if you will), it’s our job to solve hard problems. We take pride in our ability to do so. We want to make that next test case work. Taking a step backward and reverting the code you just wrote (that doesn’t work) is an admission that you’ve made a mistake. Admitting this mistake is especially hard to do when you’re working on an “easy” problem.
Second, both of these options require you to THINK. It’s tempting to think that if you tweak a conditional here or extract a method there you’ll see a green bar soon. This rarely turns out to be the case. Even the easiest problem is going to require you to stop and think about the solution; probably more than you expected to.
If you run into this, Stop. Think about the problem. Discuss it with your pair. Then, take another crack at it.
Lesson #2: Commit Often
Today, my pair and I ran into all of the clues listed above, and failed to stop. It was at this point that we got burned by lesson #2. We realized what was going on, and wanted to revert to our last green bar. We hadn’t committed in 90 minutes. We were stuck with broken code. Oops.
I don’t have a strong opinion on when you should commit. Ideally, I would say you should commit on every green bar, or after every refactor step; whichever is easiest to remember for you. Of course, some teams are cursed with long running unit tests. Since you don’t want to commit without running your tests; this makes it difficult to commit so frequently. Do what you can to keep your tests running quickly, but in the meantime, find some balance between committing often and not letting your tests slow you down.
Lesson #3: Focus on your work — No Distractions
Today, during the “embarrassing pairing session”, I had an interesting email thread zipping through my phone, which dutifully beeped at me every few minutes. Every once in a while I’d try to keep up with it, meanwhile completely losing my focus on the problem and relying on my pair to get me back up to speed when I was done.
Please, be wary of checking your email or other distractions when pairing on a problem. If you’re not at the keybaord, your job is (among other things) to help figure out the next test, watch for warning signs like the ones I listed above, and maintain code quality. You probabaly can’t (I know I can’t) do any of these things while checking your email, or carrying on a casual conversation with a friend. Also, respect your pair. If they’re working, you should be too. They’re going to resent you if you don’t pull your weight.
By: Kevin Baribeau
Agile 2009 Presentation Submissions
Agile 2009 Conference
At Point2 Technologies, we develop software following Agile principles. We are always interested in discovering, learning, and sharing new and better ways to embrace agile development practices. That is why we would like attend and possibly present at the upcoming Agile 2009 conference.
We have prepared a few presentation proposals which we have submitted to the conference’s official website:
Being an Agile C*O
How to give great feedback and why it’s so important to an agile team
Drunken Heroes
Hiring for Agile as Demonstrated via The Dating Game
*Please note that you do need to create an account or login to be able to view the links.
By: Jesse Webb
Agile Model Driven Development (AMDD)
One of the sessions I attended at SD West was ‘Agile Model Driven Development (AMDD) by Scott Ambler. Scott started the session by having us form groups of 4-5 people, and then gave us 3 assignments to work on – one each in the Traditional, Mini-Waterfall and Agile methodologies. At the end of the 3 assignments we compared the team ‘scores’, and most teams did best in the Agile assignment. We then had a mini retrospective of what went well and not so well in all 3 approaches. One of the important revelations was that each team interpreted the same assignment a little differently.
Agile Modeling (AM)
Types of Agile Models: The type of modeling is not important. We can use any tool that works for us. The model can be represented in UI sketch or sticky notes on a whiteboard, as Acceptance Tests or a Domain Model or a UML Sequence Diagram.
- Fulfill their purpose
- Are understandable
- Are sufficiently accurate
- Are sufficiently consistent
- Are sufficiently detailed
- Provide positive value
- Are as simple as possible
Agile models are just barely enough!
Scott presented some comparisons between the Traditional, Waterfall, Iterative and Agile approaches. The data, slide decks, and original questions can be downloaded from www.ambysoft.com/surveys/. One interesting slide provides data that shows Agile teams do quite a bit of planning, which dispels the misconception that Agile teams don’t plan! Most Agile teams plan using sketches on a whiteboard or similar; some teams capture this information (usually digitally).
The session also included some information on Agile Documentation:
How CRUFTy Are Your Documents?
Calculating the effectiveness of a document: Effectiveness = C * R * U * F * T
Where:
C = % of the document that is Correct
R = Chance that the document will be Read
U = Chance that the material will Understood
F = Chance that the material will be Followed
T = Chance that the document will be Trusted
What are Agile Documents?
- Focus on stable, not speculative concepts
- Are executable first, static only if you have to
- Maximize stakeholder ROI
- Are concise
- Fulfill a purpose
- Describe information that is less likely to change
- Describe “good things to know”
- Have a specific customer and facilitate the work efforts of that customer
- Are sufficiently accurate, consistent, and Detailed
Some other useful resources on this topic are:
- www.agilemodeling.com/essays/amdd.htm
- www.agilemodeling.com/essays/bestpractices.htm
- www.agilemodeling.com/essays/tdd.html
- www.agilemodeling.com/essays/agileDocumentation.html
By: Veena Mankidy
Should I use PUT or POST for a CREATE operation in REST?
POST is for CREATE, and PUT is for UPDATE and CREATE. Ok, they both allow CREATE, how should we choose to use PUT or POST for a CREATE? Let’s say we have an animal adoption service. We have /animals to give us a list of all the animals for adoption. Let’s say we allow the user to create a category to group the animals together, such as /animals/dogs/ to list all the dogs for adoptions. Meanwhile, /animals/dogs/{id_of_a_dog} will give us the details of a dog for adoption. Now, we want to create a new category “cats”, which will give us /animals/cats. We want to also be able to add a cat for adoption. Should it be PUT or POST?
The Method Definitions of HTTP says that “The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.” And “The PUT method requests that the enclosed entity be stored under the supplied Request-URI.” The document also mentioned an important point “Methods can also have the property of ‘idempotence’ in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.”
In other words (plain English), we need to ask the following question:
- Does the user know the URI? Do we allow them to derive and decide the URI for the object to be created?
- What is the effect of the call to be executed twice? Is there no duplicated object created?
If the answer to both questions are true, then we should use PUT to create the categories, which means that we will PUT the request to the desired URI (animals/cats).
If the answer to both questions are false, then we should use POST to create (in this case the cat for adoption), which means that we will POST the request to the parent URI (animals/cats), in which case the response shall give us a new URL (e.g. http://somehost/animal/cats/{id_of_the_cat} ) to identify the cat that we have just created. Executing the POST again with the same request will end up creating an entry for the second cat to be adopted.
Of course, rules can be bent under certain circumstances, but we should remember “the principle of Least Astonishment” as mentioned by Scott Meyers in his “Better Software – no matter what” talk given at SDWest, which is to strive to maximize the likelihood that user expectations about an interface are correct.
By: Nyik San Ting
Software Quality
A number of the sessions I’ve attended here at SD West 2009 cover the same theme: software quality. There are a number of practices that can ensure quality; most of them involve the same thing – feedback.
- Requirements analysts can build prototypes to get rapid feedback from usability tests before building any code – time frame: hours or days
- Developers can write a unit test before each bit of production code to get quick feedback – time frame: minutes
- Business analysts can pair with QA roles to develop acceptance criteria / acceptance tests for each user story – time frame: hours or days
- Developers can run continuous intergration test suites to get feedback on whether they broke existing functionality – time frame: seconds or minutes
- Executives and product owners can communicate their vision for the product or feature, so the team can work toward common goals. Team members then can constantly validate what they are working on, and make design choices based on shared understanding of priorities – time frame: continuous
- QA teams can do exploratory testing on working code to find subtler bugs, usability problems, spelling and grammar mistakes – time frame: hours or days
- Developers can peer review each others code to find code smells and spot potential bugs early – time frame: hours
- Developers in some languages can use strong typing systems to their advantage. Strongly typing parameters and return values to validate input and output – time frame: instant
- Developers can use static analysis tools that help find places your code is likely to do something other than what you intended. Some of these tools are shipped with your compiler or IDE, but you can always get more detailed ones, and you can write your own to enforce local coing standards. These tools can be part of your continuous integration – time frame: seconds or minutes
- Agile teams can estimate task sizes to identify risks as early as possible – time frame: 1 hour
One thing that was empasized over and over, was that developer and tester are two very different roles. Developers want to write code that works; testers want to break it. Developers will always need that foil, trying to break their code using just as creative techniques as developers are using to write the code in the first place.
TDD is a method of development and code design, not a method of testing. People often get this mixed up because of the name. Even if TDD reduces your bug count by 95%, your QA team will have plenty of work to fill their time, doing what should have been their role in the first place – exploratory testing: testing the unknown-unknowns (everyone who said this, first felt the need to apologize for the Rumsfeldian phrase – you know they must really mean what they are saying, because nobody’s going around quoting Donald Rumsfeld just for the fun of it).
By: Todd Sturgeon
Share on Facebook
Recent Discussions