In fact, your own ability to keep up with the latest trends have suffered because only you know how to keep things working. To help manage time, you have implemented universal standards and tried to funnel requests to architecture review boards or other planned meetings. Developers routinely work around the system, complaining that process holds them back, but you know that these things are there for the good of the company so you reinforce the policy to try to keep control.

— Kevin Hickey

This is a good general description of several EA groups I’ve worked with in past companies. The EA is often far away from the day to day of development and looks to keep control by implementing layers of controls. Not much different then change control boards that attempt to stop change by adding a meeting/paperwork tax to any request. This is where so many EAs fail to add any value and end up becoming another impediment to producing working software. I hope this is changing as Agile has moved to the mainstream, but I fear it is not the case.

Some consultants at our office needed to be able to roll back a Jenkins project that deployed to staging and production sites in case of an issue. The project had been setup to allow for a typical git checkout and then ended up using a php build tool, phing, to essentially rsync up to the servers.

Turns out ‘Parameterized Builds’ was able to resolve this. It took just a few steps:

• Click ‘Configure’ on the project.
• Check ‘This build is parameterized’.
• Add a String Parameter with the name GIT_COMMIT and a default of ‘master’
• Under Git > Branches to build, add the parameter as $GIT_COMMIT
• Save

This allows you to specify the commit SHA for each release. If you need to roll back you just run it with the specified commit SHA. This can be configured to use git tags as well. Inspiration of this came from this post.

Not long ago at a user group I saw a strange piece of sample code like this on an overhead projector:

1
2
3
4
5
6
7
8
9
10
11
12
class Person {

  constructor(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }

  fullName() {
    return this.firstName + ' ' + this.lastName;
  }

}

I chuckle a little bit inside. I’ve heard plenty of arguments over the years that Javascript’s prototypical inheritance was the right way to do things and trying to force traditional OO on Javascript was doing it all wrong:

If you’re creating constructor functions and inheriting from them, you haven’t learned JavaScript. It doesn’t matter if you’ve been doing it since 1995. You’re failing to take advantage of JavaScript’s most powerful capabilities. — Eric Elliot

It turns out ECMAScript 6 has officially added class style OO to the language. So the needs of many occasional Javascript developers to have a more familiar looking construct that would be at home in Java, C#, or Ruby eventually won.

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.