I recently attended a meetup for Enterprise Architects. I had to deal with the EA world years ago when I was reorganized into managing a brand new Enterprise Architecture Department. I remember trying to make the best of it and even being hopeful that EA and Agile could be combined. I only stayed in the position about 9 months before moving onto another Application Development Manager at a new company.
I ended up leaving the meetup quite early after the discussion veered heavily into consulting, no one listening to the EAs, enterprise data models, and governance. When the topic of coding was brought up the consensus was EAs don’t code. At that point I realized I was in an alien environment and it was time to exit.
Architects and Enterprise Architects are widely disliked by many developers. The reasons are numerous:
- Enterprise Architects are often very siloed and rarely interact with the rest of the developers.
- EAs sometimes take pride in statement’s about not coding, but insist on choosing development tools and platforms for the organization.
- Governance is used as a stick to force developers to only use approved technologies
- Documentation and EA Frameworks are valued over making progress on solutions.
Having transitioned back to software based companies I can’t see ever stepping back into a company that actually has an EA department.
I contributed some pull requests this year to several projects including the classic Jenkins Chuck Norris Plugin. Some of them were accepted quickly, others had a bit of back and forth and a few sat for months. My pull request for the Chuck Norris Plugin attempted to fix an issue where the large Chuck images no longer showed up because Jenkins had changed its’ layout design. It took diving back into some Java and brushing up on Jelly templates to figure out what was going on with the bug. After some testing I submitted a pull request and hoped to be able to integrate the fix soon after.
That was December of 2014. The fix was finally merged in November of 2015. I don’t have any negative feelings about it. People get busy. It’s open source.
At some point people get bored with projects, move on, don’t have time, or they don’t work in the language anymore. I think there’s two reasonable ways to handle this:
- Hand off maintainer duties. It’s the best option if you have someone interested in taking over the project.
- Post your explanation for not updating the project on the README to let them know pull requests and issues probably won’t get any attention. Then someone who cares enough can fork it or at least it’s use will slowly dwindle down.
In the Chuck Norris case they got a new maintainer, and my little fix is finally merged in and released.
I volunteered to help out as a TA for RailsBridge Sacramento this past weekend at Hackerlab Sacramento. We had 60 people show up to build some Rails in one day. Many of them were brand new to programming or Rails. My section had a lot of people with some development experience in other languages like Java, C#, C, or Scala.
The energy level and overall interest was great. I taught Oracle Java classes years ago and sometimes the majority of the class was only there because their managers made them attend. Teaching disinterested people is stressful and not fun. Even though they were giving up a Saturday almost everyone stayed and coded through the entire day.
As a TA I rotated among people nudging them in the right direction, troubleshooting errors, explaining Rails and Ruby idioms, and discussing the local job market. My only break turned out to be the pizza lunch but I was working off the energy of all these motivated people. Everyone in our group got through the main exercise and built a simple Rails app and got the chance to add extra features like a login with Devise. And even if most of them never build another Rails app they can carry the paradigms that are common in many web frameworks like migrations, integrated REPLs, generators, templates, and ORMs.
The diversity of the group exceeded by assumptions. It’s refreshing to see that the next generation of developers won’t look like the current white male majority. It was rewarding to explain to many people how they could approach breaking in or breaking back into a development job by just showing some motivation and the ability to learn. Hopefully some of the attendees will some day bootstrap more underrepresented groups into software.
As working remotely especially as a developer has become easier over time, I still see a lack of any real remote work in the Bay area. Despite a very expensive living expenses, office space, and almost zero unemployment among developers, companies rarely seem to consider remote work. I assumed as the demand for developers intensified we’d see a corresponding interest in adding remote workers to teams or even going fully remote, especially with companies like 37 Signals and others paving the way.
The typical Bay area company is looking for on-site talent despite the cost and difficulty of recruiting. With over 20 years of experience now I acknowledge it’s nice to have a team co-located, but certainly not at the expense of having a good team. There are some incidental communication and collaboration benefits of working side by side in a room with a team, but many of these same benefits can be mimicked using technology. Some of the tools that are commonplace, cheap, or free are:
- Remote Pairing Tools (ScreenHero, tmux, VNC, Skype in a pinch)
- Hosted Project Trackers (Pivotal, Trello)
- Source Control with built in Code Reviews (github, gutbucket)
- Issue Trackers (ZenDesk, Redline)
- Video Calls (Skype)
- Shared chat platforms (Slack, HipChat, Campfire)
So why are we still largely living in the working experiences of the 1990s?
I’ve used plenty of project tracking tools over the years many of which I detested and a few I was OK with. AgileZen was a pleasant surprise when I came across it and I wrote a review and lobbied for using it at my current company as a Kanban style lightweight tool. It worked fine for us for a year or so, but gradually we noticed it was getting no love. The UI in tools like Pivotal Tracker were getting more responsive and event driven and AgileZen was stuck in the old request response cycle with a smattering of AJAX. Eventually it was obvious to us that it was dead software walking.
Rally Software promised that the beta would improve everything, but in the end they never released it. I’m sure it was a business decision where they didn’t see enough upside in improving it and decided to just eke out a profit with the current dwindling subscribers.
We ended up back in Pivotal Tracker which has served us well, but I still wish there was a nice Kanban style replacement for AgileZen.