Matthew Botos

Mock objects are another one of those software concepts that are interesting but useless until you see how they can make life easier. A few of the talks at Code Camp helped me turn that corner and see that they’re quite useful for unit testing. Namely, they allow you to unit test a class while mocking its dependencies, which frees you to focus on the class being tested instead of dealing with the overhead of a real database or web service.

For an initial hands-on experience, I refactored some unit tests I wrote last week for a business class that called a web service. All that really needed to be tested was the handling of various data and exceptions from the web service, which were one-liners once I figured out the syntax of Moq. Writing tests this way also exposed some areas where code was overly coupled; my business class was doing a lot to manage the external service.

The tests are now quicker, the code feels a bit more solid, and I’ve got at least a foothold in understanding mocks for testing and their impact on software architecture.

I’ve been doing a bit of pair programming recently, and getting a different perspective from it. For one, it is nice to take a break from the usual solitary keyboard banging. Having two people makes bug hunting a little easier, and forces you to really think about what you’re doing - and why - so that you can explain it to someone else.

It’s also an interesting study in personal efficiency and style; I’ve been able to share a few time-sharing shortcuts and preached a bit of test-driven development by example. I’ve learned a bit, too,  finding some better ways to rework code I previously wrote.

I went to my first code camp with Philly.NET this weekend, and was impressed with the variety of speakers and overall attendance. For as many great online resources as there are today, sometimes it’s much more effective to see new technologies and methods explained in person.

The quality and polish of the presentations varied, but were overall pretty good. Being a code camp, most quickly moved from slides to live code, writing and debugging on the fly while taking questions from the audience. As always, it was enlightening to see how other people write software, both in terms of style and the tools they choose to write better code faster.

(more…)

The most recent AgilePhilly talk was on scrum adoption, and the ensuing discussion showed that it’s not easy for anyone to implement it fully. I’ve seen top-down mandates and looser directives, but the real driver seems to come down to the culture of the team.

Where people are used to processes and metrics, it’s just another system to adopt. Where they’re not, it tends to be a just-in-time approach that only uses what’s needed. That really frustrates me sometimes (if you say you’re going to do something, you should do it right!), but it seems pretty common for the transition to come in smaller steps. And to look at it from an agile perspective, there is some value to only building what you need, be it software or process.

Another interesting idea that came up was having scrum masters with program management backgrounds actually do quasi pair programming with the team. This would have some interesting benefits; program managers would see why a supposedly simple change takes two days of digging through ugly legacy code, or how test-driven development produces more solid code that’s less costly to fix later.

Forget Milton’s Red Swingline; you want the Bling Stapler!

I’ve always been a big fan of making the computer do the arduous part of the work so I can concentrate on the more interesting parts. When writing software, that’s generally meant relying on terse or sophisticated languages like Perl and Matlab. I’m currently taking it to the next level, though, by using code-generation tool and frameworks to generate complete code layers with full unit tests.

(more…)

I enjoy Morgan Spurlock’s work; both Super Size Me and 30 Days provide a fresh, provocative look at modern issues. It got me thinking: how would each of us cope if we had to live a lifestyle opposite to our own for 30 days?

The first step in this thought experiment is figuring out what that personally meaningful opposite is, be it a belief, lifestyle, or position on a certain issue. For me, I think something that shapes my life significantly is the regular use of computers. It’s how I earn a living, communicate with friends and family, and even meet women. How would I fare if unplugged for a month?

(more…)

It’s pretty cool to see one of my former projects, the Unity enterprise social suite, getting plenty of coverage at the Enterprise 2.0 conference. (Naturally, the news came to me through the social grapevine of my del.icio.us network.) I was involved in the first year or so of the project, and it looks like it’s really evolved - this photo by David Terrar gives you a hint.

As noted in the articles, it was a big undertaking with lots of technical challenges. Sharepoint seems a little overemphasized; we also built a handful of custom web applications, feed infrastructure (ATOM as well as RSS), Google Search Appliance integration (one of my contributions), NewsGator Enterprise, and security.

Of course, the bigger challenge in any enterprise is cultural adoption by employees and management. To that end, deploying enterprise 2.0 takes passionate advocates from project management to grassroots early adopters. The Unity team has carved a solid beachhead there, so it’ll be exciting to see how it continues to grow!

I’ve been in my new job for 6 months now, which is long enough to take a look at the bigger picture of that change:

The transition was tougher than I expected; changing companies is a much bigger shakeup than changing projects. I had gotten comfortable with the latter; even though there was an adjustment period, the corporate culture was the same and I had grown a large network there. It probably took a good three months to assimilate, and I’m still putting together the bigger picture of this new company and new industry.

The proverbial grass is greener in spots, though interviewers conveniently don’t mention the brown patches, or the occasional dog turd. The project was in worse technological shape than advertised, though I’ve learned a lot about good & bad architecture, reverse engineering, and refactoring in the process. There’s also a lot of opportunity in the turnaround; I got to be scrum master and lead the implementation of test-driven development and other modern practices.

(more…)

In a reassuring sign that my current senior management understands a bit of Enterprise 2.0, our CEO launched an internal blog this week. So far the posts have been short, casually-written glimpses of what the CEO sees and most employees don’t. I think that goes a long way towards helping us peons understand the king’s strategy.

I was also pleased to see that comments are enabled without any moderation. It’s running on a vanilla install of WordPress, so comments are as anonymous as you choose to make them. Being a shameless self-promoter, I not only signed mine, but threw my LinkedIn profile in the URL field. No one else thought to do this, so my ingenuity actually earned me an introductory visit from the vice president of information technology, who I’ve worked under for almost 6 months. More than anything else, that proves how enterprise blogging breaks down barriers.