Surface Pro Coming This Month?

Rumors are flying that Microsoft will release the Pro version of its Surface tablet this month. The most interesting news I’ve seen on the topic is that Office 2013 won’t be included. As an MSDN subscriber, this wouldn’t be a big deal for me. However, I’d be pretty annoyed as a regular consumer.

Taking off my techie hat for a moment, it doesn’t make any sense. I can buy RT, a “lite” version of Windows, and get a free version of Office. Alternatively, I can pay $300 more for the Pro version that gives me less capability out of the box. If I want Office, I have to pay even more.

Now, putting my techie hat back on, I understand that the Pro version gives you a full version of Windows, and that’s what you’re paying for. You can install your old copy of Office 2003 or download a free alternative like–something you can’t do with Surface RT. If Microsoft didn’t provide Office with RT, there would be no offline alternative available, and that would be a huge problem. That said, it still seems like a silly move to me. Think about every feature graph you’ve ever seen that compares different versions of a product: the checkmarks usually don’t disappear as you move to the “advanced” versions.

The reality is that Surface Pro is intended for business and professional users. The Home & Student version of Office that ships with Surface RT probably isn’t sufficient for them, and they’d likely upgrade to a better version of Office anyway. So why not throw the average Joe User a bone and include a free version of Office? Is this just another example of corporate greed? It sure feels like it.

On a lighter, less-ranty note, I’m very curious to see how Surface Pro users will really use their tablets. I convinced myself that the things that appealed to me with Pro weren’t realistic uses. I’d love to install Visual Studio, but I’m not going to sit down and develop applications on it. I’d like to install Photoshop, but I’m not going to be editing graphics on it. Or… maybe I would, and I’m just trying to convince myself that I hastily made the right decision by opting to not wait for Surface Pro. I’m also interested in the difference in battery life, as that was another key justification in my decision to go with RT. I think I have a few co-workers that are ready to pull the trigger on a Pro as soon as it’s available, so I should have answers to these questions soon.

Serif DrawPlus

I’ve used an old version of Photoshop for all of my crappy, makeshift graphic needs over the past decade. It’s served me well, but I’ve been wanting to get something newer for a while. More specifically, I wanted a vector drawing application. I’ve loved Photoshop, making Illustrator the obvious choice, but I’m not interested in the $600 price tag. Adobe does have more attractive, subscription-based pricing options, but I’d rather pay once and be done with it.

With that in mind, I headed to the internet to explore options. I found DrawPlus from Serif, which has a free-to-use Starter Edition. I downloaded it to check it out and liked it very much. What I liked most was the How To tab that changes as you select different tools. I’m far from a graphics pro, and I usually stick to the tools that I know. This gives me the ability to learn new tools on the fly. Serif also offers many online tutorials, which is nice.


I was trying this out last week, and Serif was running a sale where one-version-old editions were 90% off. I scooped up DrawPlus 4 for just $15, and I’m glad I did. From what I can tell, this sale is no longer in effect, but it might be worth checking in from time to time. Or maybe it’s a year-end offering that they do–who knows? You can get the latest version for $99, or you can just stick with the feature-limited Starter Edition if you have basic needs.

Oh, and if you’re looking for a less expensive alternative to Photoshop, Serif offers a product called PhotoPlus. It also offers a free Starter Edition that I’m likely to check out. Based on my limited experience with their software and my basic photo and graphics editing skill, I’m a fan of Serif!

Peer Review Early, Peer Review Often

Another one of my never-ending flow of initiatives from the past year or so has been encouraging and promoting peer code reviews. This started as an extremely bare-bones process. Before committing a change to source control, a developer would grab a peer and simply walk them through their changes. My thought here was to get a second set of eyes on the code to catch obvious problems and force the developer to review their changes to avoid silly mistakes (e.g., Oops, I left my email address hard-coded in there!)

The next phase of this agenda would be to introduce a more formal code review. Grab a conference room and a peer or two, and walk them through the solution. As a reviewer, it’s hard to understand what’s going on by looking at a single file in a single changeset. You get no context about what’s trying to be accomplished. I can tell you if you miss a null check, but I’m less likely to notice if you’ve violated design principles without knowing much about the bigger picture. I’m still working on how to make this part of the process work, but that’s not what I’m writing about today.

I was watching a webcast about peer review, and it opened my eyes to a huge flaw with both of the processes introduced above: they occur after development is complete. We all know that the earlier a problem is identified, the less costly it is to fix. By waiting until the end of development to do a peer review, we’re ensuring that problems identified by peers will be as costly as possible. Peer reviews can also identify optimizations that could save development time. Refactor that function into a common place so that each class isn’t re-implementing it the same way. Boom, you just saved all the time that would’ve been spent re-implementing that function in subsequent classes. Peer reviews often result in a list of items that need refactoring. If you wait until the end, you’ll have a bigger list that takes more time that is ultimately less likely to be completed.


In addition to the time-saving opportunities, there’s also a human element that comes into play. When I think I’m done with a project, the last thing I want to hear from my peers is everything that’s wrong with what I came up with. In that scenario, I’m more likely to be resistant and defensive to suggestions. You think I should take all this stuff out of those TWENTY classes and move it into a base class? We’re deploying next week–there’s no way we can do that!

Additionally, the presenter in the webcast, Karl Wiegers, pointed out that peer review isn’t–and shouldn’t be–limited to code. The earlier you catch an error, the less costly it is to fix. So why not spend time peer reviewing the requirements document? A missed requirement that comes up late in the development process is usually a mess. Utilizing peer review on the requirements document might save some headaches later. As a bonus, you also introduce the requirements writing process to your peers, potentially adding depth to the team. This helps strengthen the team’s bench because even junior members can become familiar with the process of defining requirements before it becomes necessary for them to do so. The team also benefits from being more familiar with what’s in the pipe, which makes starting new development less of a telephone game.

The final message that I want to leave you with is exactly what the title suggests: peer review early and often. Review requirements documents and they’ll become more consistent, better defined, and knowledge will be shared between team members. Peer review code before it’s done to identify optimizations that can save development time and reduce the need for refactoring later. Peer review designs and test plans to improve quality and grow the team.

Resolutions for 2013!

Ahh, New Year’s Day—life’s sprint planning. We reflect on the year behind and set goals for the year ahead. I’ve not been much of a resolution person in the past. Sure, I’ve made a resolution here and there, but I’ve never written it down or tracked my progress.

I’m going to do it different this year, though. I’ve got the perfect mechanism for documenting and following-up on my resolutions: my trusty blog. I’ll jot down my goals here and follow-up on them next year. Sounds like a recipe for success, eh?

So, without further ado, here’s what I’m resolving to accomplish in 2013.

Personal Goal: Be Healthier

I consider myself to be in “okay” shape. Like most people, I’ve got a few extra pounds to shed, and my eating habits are probably a bit sub-standard. (I can’t help it—I love Whoppers. The Burger King kind.) My goal for this year is to exercise more, make better food choices, and end the year 15 pounds lighter than I am currently.


  • Run 3 miles each week
  • Manage restaurant portions

Professional Goal: Reform Agile Practices at Work

For years, I’ve felt like we haven’t been doing agile “the right way.” I could point out things here and there that didn’t agree with my vision for how things should work, but I also didn’t have a plan or vision for how to fix it. In the past month or so, I’ve done a lot of agile soul-searching, and I’m committed to making changes that I think need to be made to get us firing on all cylinders. I’m going to create a lean, mean, agile-software-developin’ machine!


  • Improve the team’s velocity each quarter
  • Maintain a prioritized backlog for the team