in

Telligenti

Serving up fresh ideas every day, Telligent style

Dave Donaldson

May 2008 - Posts

  • Should Developers Be Paid Royalties?

    I just read a very interesting article on the NY Times about Michael Hollick, a relatively unknown actor who did the voice and motion-capture work for Niko Bellic, the main character in Grand Theft Auto IV. The basis of the article is that actors who perform work for video game publishers are not given royalties on the sales and distribution of those games. In other words, why are actors being paid differently for video game work as opposed to TV shows or movies or radio? In those traditional mediums actors are paid royalties every time their TV shows or radio commercials air. Rockstar Games has spent millions marketing their latest creation on TV and radio, almost all of which contain the voice work of Mr. Hollick, yet he doesn't see a dime from all those commercials.

    Oh, he was certainly paid decently enough for his work, about $100,000 over the course of 15 months, but that's nothing compared to the cast of Friends in their last season when they were each paid $1,000,000 per episode and of course continue to roll in the royalty money from syndication. I admit it's an extreme comparison, but still.

    The article goes on to point out that the real fear with the video game studios is that by paying royalties to actors, does that then open the door for all the artists, designers, and programmers who develop the game to also collect royalties? Like I said, it's a very interesting article.

    So that got me thinking about the rest of us developers who don't work on video games. Should we be paid royalties for our work? Think about that line of business app you wrote for a client that helped increase sales. Should you get a piece of each new sale?

    What about the call center app you wrote a bunch of code for? The one that saves the company tons of money every time they bring new users into the system. Why shouldn't you get paid for continuing to save the company money?

    Or what about the cool online community that you were instrumental in launching? You know, the one that's adding thousands of new users a month, thus greatly increasing the advertising revenue for the site. Shouldn't you get a slice of that advertising revenue for each new user?

    I realize this is a bit out there, but I don't think it's as far-fetched as it seems. I mean, think about why actors are paid royalties: because they can continue to entertain people over an extended period of time, and because the TV and movie studios profit from that, so should they. So how is that any different from what we do? As software developers we provide value to our customers that last for extended periods of time, and the companies for whom we performed the work either profit from that work, save money from that work, or both.

    I understand trying to track such things would be quite the undertaking, and I offer nothing other than my thoughts, but obviously it works in other places. So I ask you, should developers be paid royalties?

  • Killer App: ooVoo

    Back in my Tools for Distributed Communication post, Michael Eaton asked if we had used ooVoo, the free video chat/conferencing software. We hadn't at the time, but some of us were checking it out a couple weeks ago when we were all in Dallas.

    Since then it's pretty much replaced Skype for when we want to chat remotely. And nowhere is that more apparent than in our daily stand-ups. And how does a team hold daily stand-ups when everyone is remote? Like this:

    image

    Sure, it looks like a geeked out version of the Brady Bunch, but it works really, really well. ooVoo supports up to 6 people connecting into the same video conference, and the quality is quite good for both video and audio. Every now and then you'll notice a slight delay or hiccup in the audio and/or video, but it's nothing major and never lasts for more than a moment.

    For me personally, ooVoo has helped me make a more personal connection to the people I work with for the pure and simple fact that I can see their faces on a daily basis. My use of IM has gone down because now I just call someone up on ooVoo and have the conversation face-face instead of relying on text messages in a window. It's so much more personal and therefore a much better way to communicate.

    If you work disconnected from your team, you owe it to yourself and your team to give ooVoo a shot. If you want to try it out first, feel free to add me (arcware) and call me up.

  • Preview of SharePoint Integration with CS 2008

    Do you use both SharePoint and Community Server inside the firewall? Ever wish you could integrate the two? Well, now you can by grabbing the preview release of our SharePoint Integration with CS 2008.

    This integration between the two platforms has been one of the most requested items for Telligent, so we're really happy to get this out the door. It's been in the works for several months, with Leon doing a kickass job of getting us this far. So if you're at all interested, download it, try it out, and give us some feedback.

  • Come Work With Us

    Want to work with some of the best and brightest? Want to work on cool stuff? Want to help build products used by thousands upon thousands of people? Well, now might be your chance.

    We have recently opened up a couple spots on the product team. One is for focusing on our SharePoint integration and the other is for someone to focus on performance and scalability. If you've got experience in either area and are at all interested, drop us a line and we'll get in touch. And feel free to ping me if you have any further questions or want some additional details.

  • A Method Should Do One Thing and One Thing Only

    As someone who enjoys well-written code like it's nobody's business, I get frustrated when I find methods that do more than one thing because to me, a method that *could* perform several actions is not well-written.

    For example, awhile back I came across a method named something like CreateUpdateDeleteItem. The name itself contains three verbs (actions for the grammar impaired), and not only that, but it accepts several parameters, a couple of which are used as flags for conditional logic at different places within the method.

    The biggest problem with a method like this is testing. The method itself does not subscribe to the Single Responsibility Principle, and thus contains several nested conditional statements, each of which require their own test permutation to make sure all code paths have been accounted for.

    Before I got into unit testing a few years ago, I had a much harder time convincing people of the benefits of splitting a method like CreateUpdateDeleteItem into three separate methods (other than "just because"), but with unit tests I have concrete evidence of why it makes sense to do so. It's amazing what happens when you show someone actual tests because at that point it's no longer theory, it's real. And it's usually only then that the light goes off.

    So if you find multi-action methods like CreateUpdateDeleteItem, refactor them appropriately. Your tests will thank you.

  • Lines of Code Should Be Like a Golf Score

    I get really aggravated when I hear developers talk about how many lines of code they write. You know the people I'm talking about. The ones who make brash statements like, "I wrote 25,000 lines of code last month" or "Of course it's buggy, it has 100,000 lines of code".

    What those people don't get is that statements like those scare the crap out of developers who know better. When someone makes statements like that, it tells me all I need to know about their approach to writing quality software, which is to say, severely flawed.

    One of my favorite things to do is not to write additional code, but to remove code, either because it's no longer needed or by way of refactoring. Nothing makes me happier than shrinking a codebase.

    It's not about how many lines of code you write, it's about how many lines of code you don't write (while providing the required functionality). And it's those developers who you want to work with.

Powered by Community Server (Commercial Edition), by Telligent Systems