Category Archives: Technology

Conference Calls on iPhone

I do a lot of conference calls. I love the convenience of tapping a number almost anywhere on my iPhone 6 and having it dial the number, whether it’s from a meeting in my calendar or in an email. But most conference call numbers require a pin or meeting code to connect to the meeting and for the longest time I was frustrated with having to remember the code. I finally figured out the easy way to handle the conference call and pin number.

You can provide the phone number and conference pin to the phone app if you format it like this:

1-800-123-4567;123-456-789#

That’s the call-in number, semi-colon, conference pin and pound sign. The semi-colon inserts a hard break or pause, allowing the phone to dial just the initial number. When you tap on a number that’s properly formatted, the iPhone will dial the number and the conference pin will show up in the bottom left-hand corner next to the word “Dial…”

dial_pin1

Listen for the conference call service to answer and prompt you for the pin, then tap “Dial” and the pin number will by typed in. No more remembering the pin!

Some conference scheduling software formats the number such that this works without any changes, and for any invitations you create you can now make sure to format them the right way.

If you know you need to call in using a number that’s not formatted properly, you can still set things up so you don’t need to remember the pin. Copy the phone number and pin from wherever they are, email, document, etc., and paste it into a note in the Notes app. Format it as described above, then copy the whole thing.

Open the phone app and tap and hold for a second in the white area above the number pad. When you do, the paste menu will show up allowing you to paste in the phone number plus pin.

paste_number

The phone will dial and the pin will show up in the bottom left-hand corner as before. Again, no more remembering the pin!

Testing in Perspective

With his keynote at RailsConf this week, David Heinemeier Hansson kicked the test-driven development (TDD) hornet’s nest again (video is linked at the bottom), re-igniting the always simmering debate over the role of testing in software development. While I don’t believe any of his arguments were particular new, he did talk about how he personally arrived at his current opinion on the role of testing and exposed his audience of Rubyists to the idea that the TDD gospel can be questioned.

I have also evolved to take a pragmatic approach to tests, nicely articulated by Kent Beck (DHH also cited this in his talk):

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

– Kent Beck on stackoverflow

This quote is so popular because it asserts the proper perspective in a succinct and pragmatic way. The product is the project, not the tests. Use your judgement and write enough tests to serve the needs of your project. This pragmatic approach is shared by anyone who has ever been responsible for delivering an entire working product to a paying customer.

The “entire working product” part is important because this seems to be the part that unit-test enthusiasts miss as they focus almost exclusively on low-level interfaces. Most people I’ve talked to who have worked on big projects can tell you that bugs are found in core features by QA testers or customers on products with very high levels of test coverage.

Most projects have limited time and you need to get the most from the time you have.  If you’ve spent some of that time pursuing 100% unit test coverage, to the exclusion of system testing or other improvements to the product or code, it’s almost certainly not the best use of that time.

How Many Tests?

Zero is too few, and 100% code coverage (which still doesn’t cover everything) is too much. What’s just right?

The approach articulated in Beck’s comment is to optimize the value you get from the time you spend writing tests versus the time you spend writing code. So the question of “How Many Tests?” can be answered, “Enough for you to achieve the benefits of automated testing,” many of which are about saving time on the larger project. To name just a few:

  • Automated tests give developers confidence in adding new features or refactoring existing code because running the test suite gives an initial baseline that core functionality hasn’t been compromised.
  • Tests can help define a feature or interface, helping the developer verify they have provided all requested features, especially on a large team.
  • Tests written to exercise specific bugs protect against regression, at least for those specific issues.

All of these are benefits because they ultimately save time. However, you begin to lose some of this time savings if you spend too much time pursuing 100% test coverage.

Designing Testable Code

Another point DHH makes in his keynote is that he feels that making design decisions solely to serve the purpose of testing can lead to clunky or poor code design. Again, my initial thought was that this wasn’t particular controversial and he was just stating one of many factors that any working programmer already considers every day. But TDD does speak to the role of testing in code design, so I can see where some developers would take issue with designing code that might be hard to test.

In addition to providing the benefits noted above, one of the original promises of TDD is that it would actually lead to more modular, and therefore better designed, code. Like all other best practices, this isn’t universally true. Programmers have to think about a hundred different factors when designing code, all while dealing with the fundamental challenge of creating the new features needed for their product and making them work right. Making the code testable is just one of these factors, and it does come naturally if you are testing as you go along.

As an example, brian d foy has popularized the concept of a “modulino” in his Mastering Perl book, in code, and in various talks and presentations. This design pattern makes command-line scripts written in Perl much more testable by encapsulating the code in methods you can call from test files. When writing a command-line script, you need consider whether the additional code, and perhaps slight bit of obfuscation, outweighs the benefits of easier tests.

  • Is the script complicated with lots of options? Set it up as a modulino so you you can write some tests for the hard bits.
  • Will it be around for a long time with many users? Use a modulino to make it easy to add tests in the future as it expands.
  • Is it a very simple script with limited functionality? Maybe skip the extra modulino setup.

The point is that testability is one of many factors and you need to assess and weigh all of these when you’re writing code, including how it impacts the design for you and other future maintainers. More experienced programmers will be aware of more factors and will do a better job assessing the importance of these factors over the life of the code.

Testing against components external to your program, like databases, web services, etc., can lead to some tough decisions in terms of how much to bend your design for testing. It also can lead down the road of mocking parts of your system and how significantly you want to compromise your tests as you start to mock the environment.

When you write software, the goal is to create working, performant software that can be maintained, extended, and expanded over time. You need to do so within the time and budget that makes sense for the end users. When thinking about the patterns and support frameworks you’ll use, including testing, you need to keep this perspective. You need to do some level of cost-benefit assessment to decide how much effort to put into these support structures, and the more experienced the programmer, the more accurate this analysis is likely to be. While there is no question that automated testing should always be part of this analysis, pursuing TDD as a goal in itself can lead to costs out of proportion to the benefits and run counter the overall goal of creating a useful, compelling product for users.

New Ideas, From Near and Far

NPR ran a story recently on why we miss creative ideas that are right in front of us. Summarizing the research, people rate ideas that they believe came from far away as more creative than ideas they believe came from close by. As someone who has frequently tried to sell new ideas to coworkers and management, this seems pretty plausible as one of the many obstacles to change.

Resisting Innovation

Almost all companies, from the CEO to HR to the customer support group, say they support innovation in all areas of the company. Who doesn’t love new ideas?

Well, the truth is almost everyone fears and resists change. In our tech-driven culture, it’s become almost politically incorrect to suggest that disruptive innovation isn’t welcome, but that’s the reality. People like to do what they have always done. When a business is involved they will point to “what has always worked” and fight to maintain the status quo for fear that any changes will destroy the business.

So the first challenge you face is that despite the stated love for new ideas, most people will try to shut them down regardless of whether they came from near or far.

Not Invented Here

New ideas you may have picked up from some outside source can also run into the commonly observed “Not invented here” syndrome. This is resistance to ideas, products, or solutions that have come from outside the company because of the belief that the people in the company can do better (and a host of other reasons).

This seems to contradict the far and near research, but in the NPR story, Vedantam suggests one theory for the different reactions to a new idea is your frame of mind when considering it. Things nearby seem more concrete, leading you to think about things like implementation details which are more likely to lead you to shoot holes in the new idea. When you’re thinking about something that came from far away, however, you’re “in a more abstract frame of mind” which allows you to think about possibilities without getting bogged down in details.

Presenting solutions that involve tools (like software packages) or techniques from outside the company may quickly lead technical people to thinking about the concrete details, making them more likely to see all of the problems. So the “Not invented here” reaction could be inspired by the same dynamics as those demonstrated in the near and far research.

Ask the Expert

So what’s the answer? Just forget your new ideas?

One approach I’ve had success with is finding outside consultants to help sell a new idea and possibly help with implementation. Even if you are an expert in the topic and you know how to implement the idea yourself, bringing in outside consultants who believe in the idea as much as you do can be effective.

Consultants can push through resistance in two ways. They can provide the “idea from far away” that can help management think about the idea abstractly and see the possibilities. If you can find consultants from out of town who have to fly in or webex to help with the pitch, even better.

On the reverse side, if your consultants are well known experts in their fields–and they should be–they can help overcome some of the resistance from co-workers worried about implementation details. Consultants have the experience of having successfully implemented the idea before and your co-workers will likely get a kick out of working with experts in the field.

So consultants can provide the far away perspective to help the big picture selling of the idea and the real-world issues of implementing it. On top of that, your manager might just be thinking about all the work you aren’t going to be able to get done if you’re working on the new idea. Consultants don’t invoke the same sort of resistance. Using consultants for part of the implementation allows you to come up with a fixed cost that ends when the engagement is over.

Implementing change and getting buy-in on new ideas is a popular topic, so much so that there a whole industry around it including popular books. This is just one idea I’ve had success with. I’m not a consultant and don’t have any vested interest in promoting them, but the way they can act as agents of change can make them useful even when you already know what you want to do—maybe especially when you already know.

If you’re interested in more on the rise of consulting, the folks at Freakonomics did a podcast on it. Good luck with your new ideas!