Apple, Computers, Events, Family, Personal, Ruby, Software, Thoughts, Vacations, Web

Cloudy, Cold and Hip – Two Weeks of Training in Portland

I’ve really enjoyed the last two weeks. My new employer, recently acquired Analog Analytics flew me out to Portland, Oregon for training. Portland is quite an amazing place. Skateboarders, cyclists, and runners abound, but with a laid back attitude. Its the greenest city I have ever visited. Stores seem to only dispense recyclable materials including paper bags, and foods in waxed cardboard containers. The entire city is very walkable without much danger of personal harm. The food was amazing, and the drinks even better. This city knows its coffees, teas, and beers. It has to be home to the most microbreweries of any city. Needless to say I have probably gained 5 pounds, and I am super caffeinated. Also, the proximity to all these hip restaurants is giving me second thoughts about living so far outside of the city limits. No lie, I even glanced at Portland housing prices.

It took me a few days to get oriented to the city and the work environment. The company runs out of the Ford Building, in the heart of quite a few cool restaurants and bars in the Southeast side of the city. In fact, it left me a little jealous considering the hotel is only surrounded by fast food joints.  I got a shiny new MacBook Pro (which I am currently battling to make it as “boring” as possible). I can’t talk too much about the work, but it does hit the sweet spot of what I was looking for – a small team feel with deep pockets, and a launch date.

Kristin and Morrigan joined me for the second week and did their own thing, and they had a blast. They visited OMSI, Powell Books, Finnegans, several parks, and malls, and some tasty food joints. I’m happy they got to experience some of what makes this city awesome.

I’m enjoying several aspects of the job in particular: A remote driven environment, and pair programming. Training isn’t the best test run of this environment, as I am in the office everyday for now. Once I am setup, I pick the hours. People hop online and offline, according to their time zones, availability, etc. Every piece of communication, and workflow is centered around remote teams.

Pair programming makes programming social. Despite the image that telling someone you are a programmer conjures, I really enjoy interacting with people. I remember teaming up with James, John and many others at Clayton State to tackle some large issues with our portal and other systems. Since Clayton State, I have worked on a couple teams, and it was almost always in isolation, save for 5-10 minute high level meetings. The best part is, its actually kind of fun.

Pair programming was a tough adjustment for me. I’m used to presenting a final product and defending its implementation. I have all the answers. I know what the talking points are up front, and I am comfortable because I am the authority on the subject. Pair programming is letting your guard down, and conceding as much as contributing. You are two people working on a problem together, with neither party starting off knowing the complete solution. The work is certainly slower than solo programming, as incorporating input, early refactoring, and general discussion takes up time. This team takes an interesting approach to combat some of the time drain; You can either pair program and merge directly, or work solo but your code requires a peer review before merging. The choice is yours. The solo programming option will probably act as a safety value for those days when I just want some time to myself. They also encourage “switching drivers” to vary the work. Interestingly, being the passenger requires more focus than driving, as you are trying to proactively find issues with the current approach.

I’m still struggling to embrace TDD. I don’t like the zealotry in the community when the topic comes up; presenting the only two options as either you test first, or you are just ignorant, undisciplined, or apathetic to the code you write. The truth is far from it. I figure things out by moving the pieces around – not by staring at it from a distance. That is not to say that there aren’t times when testing first is extremely useful, like when clarifying requirements. The test assertions (even with missing test bodies) is often enough to help solidify an attack plan. The amount of code coverage can be a hindrance though, as real world tests always end up being more tightly coupled than you ideally want them to be. If you make seemingly small code changes, you can end up with quite a bit of the test suite failing (all though with the same few errors repeating). If you mock and stub too much, you aren’t testing much that is useful. Even worse, the workflow doesn’t seem realistic: Write the tests, verify the tests fail, write the code, verify the tests pass. The reality seems to be write the tests (heavily guessing at the exact implementation), verify they fail, write the code, refactor almost all of your tests, and verify they pass. Given the choice, I think I’d still rather write code, then test the code to verify it does what I want in all scenarios. I’ve yet to meet a dyed-in-the-wool TDDer that sees any fault with this extra refactoring step. The subject of pre-written tests needing to be refactored seems to be glossed over. Maybe my opinion will be changed yet.

Things are looking awesome for this next step in my life! I’m keeping my fingers crossed for Railsconf tickets, since they are in my employer’s backyard. There are also a few missed restaurants I am meaning to visit next time I’m back up this way…

Advertisements
Computers, Events, Open-source, Personal, Ruby, Software, Thoughts

Change is in the Air (I’m So Excited… I’m so Scared)

Lately my work has been full of exciting developments. Inside of a week, our department head decided to tackle the single largest project in the history of our department. I am not supposed to talk about the specifics, so I apologize in advance for being vague.

The scope of this new project requires significant change in our department from our past approaches. Specifically we will need massive amounts of planning and collaboration with each other.

Until now, all of our assignments have been “Ben, make this, Luca, make that, etc”. Once the application has been written, the developer becomes the maintainer, and troubleshoots any issues with it and writes any updates for it in the future.

Advantages of this approach:

  • Faster development (only one person in the driver’s seat)
  • Troubleshooting is simplified;  Problems with program ‘x’ goes to Ben – he wrote it after all.
  • Each application is self reliant and self contained.

These could be considered “good thing[s]”, until we look at the disadvantages:

  • Mishmash of code bases, and interface design. (Not good for the perceived coherence of your team.)
  • Duplication of code
  • No integration of systems – which means walled gardens.
  • Orphaned applications when the developer leaves the department.

This approach works for the small stuff, but once you step into the enterprise arena, its a different ballgame. Clearly to pull off this beast of a project, we will need to adopt a new development approach.

So off I went to do some research on proven methods of development. I quickly found that opinions on programming methodologies are like assholes as they say, everyone has one, and everyone else’s stinks. After reading overviews of several different methods, Extreme Programming was the only one that made me sit up in my chair. The other methods seemed to reverborate the spewing bullshit ramblings of my Systems Analysis and Design instructor.

An interesting requirement of Extreme Programming requires programmers to work in pairs. An interesting approach, especially since the programming language we will be using (Ruby on Rails) is one that two people on the team are experienced at, and the other two are beginners at.  This article on Wikipedia cites many benefits to doing so:

  • Design quality: Shorter programs, better designs, fewer bugs. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.
  • Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.
  • Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
  • Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.
  • Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.
  • Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email, or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
  • Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.

If our department can adopt this method, colloborate effectively, and communicate politely, I think it will help us on this venture. It will be interesting to see how certain cowboy coders adjust to being part of a team effort.