BarCamp Tampa Bay has come and gone for 2014. This year’s event was held on Saturday, October 18th at USF’s College of Business. It was my first BarCamp event, and being billed as “a day by geeks, for geeks, and about geeks” I was really looking forward to it. I’ve written up a review of the conference in general and of the sessions I attended from this year’s event.

Bar Camp 2014  Geek Congregation
Caption: Early morning geek congregation before the conference began.

Thoughts On An Un-Conference

BarCamp bills itself as an un-conference – you don’t know the speaks or sessions in advance, as they are created that morning by people who want to sign up to speak. The idea is to let real developers, designers, and geeks from the Tampa Bay area run the sessions and the conference.

Bar Camp 2014 Drone and Robotics
Caption: Drone and robotics talk.

As this was my first BarCamp, this kind of confused me, as I didn’t know what to expect, but I went in hopeful. Speakers were supposed to get in early and sign up for their sessions starting at 7:30am. By 9:00am, I was a bit disappointed to see that the board was less than half full. In reality, the board didn’t fill up until after 11:00am. Session selection was sparse and a bit disappointing before 11am and after 3pm.

Bar Camp 2014 Session Board
Caption: The BarCamp session board.

That being said, the conference is supposed to be free-form: if you didn’t like a session, you’re free to get up and walk out and try another. There were was also a large lobby space for mingling with the local tech crowd and a day-long display of robotics stuff to check out.

Bar Camp 2014
Caption: 3D printer display and showcase.

9:00am Session: The Future of Mobile & Video

My first session sounded promising from the title. It ended up being a sales pitch session from ReViewdeos, a company that has an iOS and Android app for sharing video reviews. I stayed and listened to what they’ve built, and they did have some interesting features such as negative review resolution for business owners, replying to videos with videos, and the promise of a future API to add reviews to a business’ website.
Bar Camp 2014 Presenation

Unfortunately, the app owners had a hard time convincing people how their product greatly improved on what you can do today through YouTube or Vine.
BarCamp 2014 Speaker

10:00am Session: UI Test Automation – A Progressive Approach to Coded UI Testing

We’ve been looking into UI test automation quite a bit recently at Mercury, so this session piqued my interest too. The company presenting was Pilgrim Quality Solutions – they provide web and software solutions for the medical device and life science sectors, and much like us they use many Microsoft products.
BarCamp 2014 Pilgrim Presentation

What their presentation ended up showing is their own in-house home-grown UI testing platform. They were able to take an Excel spreadsheet developed by business users and run browser UI tests through their platform – it would translate into clicking on buttons, browsing to pages, filling out forms, and logging in to websites. How this differed from other open source UI testing (like Selenium scripts), is that it isn’t just recording and playing back a script – it’s much more robust and focused on business users.

BarCamp 2014 UI Presenter

I asked if they had any plans to open source or sell their testing solution, but they didn’t. I think a lot of people would jump on their tool if it was offered as a product.

11:00am Session: Fix Your F*ing UX

This session was led by Tyler Pitchford – an appellate lawyer who used to be a software engineer. He co-developed the infamous open-source file sharing software Azureus (now called Vuze).
BarCamp UX Presentation

His session asked the question, “Can the open-source community benefit from a better UX experience rather than more features?” He recounted his own recent bad experiences installing server software, Windows 8 failures, and the downfalls other open-source programs.

The audience chimed in quite a bit, and a consensus was formed that the cause of bad UX in the open-source community has come from many factors: bad programmers, UX being hard, programmers not talking to their users, a lack of proper education, lack of resources, and poor project management.

He also highlighted some technologies that have helped software UX: release maps, error reports, unit tests, and wiki documentation.

I believe a big part of the downfall of UX in the open-source community is a lack of communication and collaboration between developers/programmers and designers/UX professionals. There isn’t an easy way for designers to find and contribute to open-source projects that could use UX help.

1:00pm Session: What Geeks Need To Know About Business

This session was led by Matthew Thomas, a project manager for the company that built VIPRE AniVirus. He recounted how his company was able to position their antivirus software in a very crowded space that had a lot of competitors by marketing it as software that won’t slow down your computer — and make millions of dollars by doing so. His talk ended up becoming more of a lesson about marketing than running or starting a business. His take away is that there is still a lot of money to be made in the consumer products sector, and that coming up with a product that has no competitors isn’t the best avenue (as it’s probably a bad idea if nobody else has already developed a solution). He recommended finding pain points in consumer’s lives and developing solutions that help ease that pain.
Bar Camp 2014 Group

He also recommended really getting to know your users through user personas, taking lots of surveys about your product or potential product, and face to face feedback with your customers. He warned that all too often software and developers fall into feature traps and ego traps.

2:00pm Session: Crowdsourcing Case Study – Threadless

This session presented a case study of Threadless, a T-shirt printing company that crowd sources it’s T-shirt designs to the public. The talk was an interesting overview of how crowdsourcing has become the new business model for the 21st century.

Bar Camp 2014 Presentation

The presenter also provided some insights into anybody involved in crowdsourcing products, such as finding unique ways to engage with your crowd, be authentic and transparent with your users, don’t make false promises, and allow for social influence to shape your product or service.

A random takeaway from this session was that if you search for ”coolest dude on Earth” on Google, the top hit is the website for Jake Nickell, the founder of Threadless.

3:00pm Session: Digital Driven by Data

My last session of the day covered ways to use data to drive digital marketing efforts such as a site’s blog content, email campaigns, social media, and paid online advertising. Doing a bit of research into your website’s analytics and your competitor’s analytics can go a long way into helping drive more successful marketing campaigns and spending advertising money much more wisely.

Bar Camp 2014 Presentation

The best part of the session was seeing tools in use that I haven’t heard of before that I now have in my arsenal. They include:

Summary

I’d have to say my first BarCamp conference was a fun one. Almost all of the sessions were informative, and in all of them I could find a takeaway that I can apply at Mercury in my daily workday and for our clients.

I do see some areas for improvement, though. I think finding a way to have a fuller schedule in the morning and the late afternoon would go a long way to keep people from leaving early (the parking lot started to empty around 3). Also, the integration with the EventJoy service for registration and scheduling could be greatly improved. The EventJoy app didn’t really provide anything useful, and the schedule could only be seen on the mobile website.

One of the key things I want to keep in mind for next year is possibly sharing some of my interface knowledge. The amount of design and interface oriented sessions were a bit lacking, and I think the best way to solve that would be to contribute to the community.

All in all, I’ll definitely be looking forward to returning to BarCamp next year!

Resources
BarCamp Tampa Bay Website: http://barcamptampabay.org/

 

This is a question that brings out very strong beliefs on either side. On one side of the room are those who stand firmly opposed to writing tests to cover coded solutions. They claim things like “It costs more money to ‘waste’ time on writing tests.” or “I can write good code without ‘wasting’ time on writing tests.” or “I don’t know how so why bother?” or classically “No code can be written to test this.”

In spite of all the arguments (and there are certainly more than those I just listed) there is greater value in writing code tests than not.

From a developer’s point of view, there are quite a few good motivations to writing code tests, but for now, I thought I’d list the four that I think are at the top of the list for building quality, solid software solutions whether you have the perspective of a developer or not.

1. A well written test assists in thinking through a solution and forces the team to have a plan.

It is surprising how often anyone begins anything without thinking it through first. Even when we speak, many of us are often quicker to let words loose than to consider what we are going to say before saying it. But in the world of science and technology, an accident or poorly thought out solution may cost you an advancement, or financing, or worse, a good relationship.

2. Good tests help to prove the stability of a constructed solution.

Often times, writing software is compared to constructing a building. There are many similarities – an architectural blue print or plan is always a first step. Software is put together in sequence just like a building is put together in sequence, always starting with the framing and finishing with the “decor” or bells and whistles. As a building is constructed, inspectors come in and check to make sure that what is being built is good quality, and is safely and solidly constructed. Once something passes inspection that is the “proof” of its quality. Well written tests are just like a good inspector – they are the proof that the constructed solution is well crafted.

3. Unit and integration tests help to avoid regression when changes are made to the solution.

Sometimes when a change is made, especially with large, complex solutions, it is difficult to know whether or not that change will affect other areas of the software. Have you ever had a strand of Christmas lights where one single bulb being out affected all bulbs of that color? Wouldn’t it be great if there were a visible indicator as to which bulb was broken so that you didn’t have to check each and every bulb individually until you got the right one swapped out? Well written code tests provide that indication. When one piece of code is changed, there can be a ripple effect and well written tests can point to the exact method or function that caused the disruption and all the methods that were affected by it.

4. Tests can serve as notification when a change violates a business rule or assumption.

Every organization struggles with good communication, and even those that excel at communicating well still have moments when someone makes a change and forgets to inform every person necessary, or perhaps someone will need to change a rule but doesn’t remember that there is more than one reason that rule is in place. People are prone to forgetfulness and mistakes and well written tests will notify the team when a rule has been forgotten or mistaken. Good tests help to let us know when something has been forgotten or mistakenly changed or perhaps just flat out misunderstood. Good tests give an entire team a heads up when a rule or assumption should be modified to fit a previously unknown scenario, and they also serve as a double check against changes that perhaps shouldn’t have been made because of the rules and assumptions they violate.

Anything well-crafted is worth taking the time to ensure its quality, and software solutions are certainly no exception.