Tag Archives: software development

RailsBridge NYC

Posted on by

I am a coder and hiring manager for Rails developers. I am father of a daughter who aspires to a career in science and technology. For both reasons, I am grateful that there are programs like RailsBridge that introduce Ruby and Ruby on Rails to women interested in the technology and hopefully, a career in software development.

Bianca Rodrigues provides a nice, brief description of the RailsBridge NYC workshop June 6th.

It was great to meet other newbie Ruby developers who were going through some of the same beginner pains that I was. The workshop was a positive experience, and gave me the push I periodically need to keep myself immersed in technology. (read the entire post)

There is a large body of research and writing (including my own paper) on the fact that women are drastically under-represented in software development disproportionate to other careers in science and technology.

If you are an experienced developer, please consider volunteering. I participated as a TA and it really only took two evenings and one full day of my time to be of use to this great program. The experience of coaching is both a joy and a refreshing opportunity to see what you do through other people’s eyes.

Dear agile consultant – hiring criteria for coaches and mentors

Posted on by

play at your own riskDear consultant who uses “agile” as part of your brand,

I am a possible customer who embraces agile principles, practices agile techniques and has done so for years.

I admire the tenacity and talent it takes to build a business in consulting.

The best of you offer your clients techniques, language and a way of thinking that can better lives and turn around companies: advising them in ways to change their own organizations, bolstering their courage to experiment, helping them learn to iteratively learn, inspiring them to foster teams, empower individual contributors, incrementally improve, and helping them grow past dependency on your services.

Here’s how I judge whether a thought leader is a worthy mentor:

  • Your reputation among those of your peers I know and respect.
  • Do you provide context/share credit: “This is where it originated, this is who popularized or researched it, this is who’s written well on it. This is my version of it.”
  • Do you espouse principles: “This is about defining work that builds equity because it offers real benefit to end users and a way of working that entrusts individual contributors of diverse talents to collaborate within teams to deliver that benefit.”
  • Are you frank: “Most companies who try this fail. Most managers who try this will not change their own behavior enough to allow their teams to succeed for them.”
  • Do you embody the principles: “It is about your team(s). Not me. I do not have right answers only experience, a willingness to listen, and techniques to help us figure out what you need to do to help yourselves.”

Conversely, these are the bad smells:

  • Celebrating the widespread adoption of “Agile” without acknowledging most “agile” adoptions are crap.
  • Celebrating scale not individual team excellence.
  • Focusing on techniques not principles as if “stories” and “iterations” were magic.
  • Talking about software tools before disciplined engineering practice.
  • Talking about “value” and “productivity” as if a leader’s understanding of these terms were not a/the major obstacle to their workers ability to perform.
  • Jamming agile practices into a contradictory way of thinking: “Agile process manager” anyone?
  • Coining new jargon for a slight spin on existing practices: It looks like a timebox, smells like a timebox, tastes like a timebox. “I call it creato-inno-rations™.”
  • Putting yourself above the problem: Just because you were really good when you practiced doesn’t mean you are a brilliant coach. Just because you’re a brilliant coach doesn’t mean you can do my job better than me. Just because you can do my job better than me doesn’t mean paying you to not do my job provides my company value.
  • Overheated claims of personal invention/Not giving credit to others. Sorry guys (and I mean guys), Mary Poppendieck was talking kanban and software development fifteen years ago. You’ve advanced the craft, you’re changing minds, and you may be very good at what you do but you are not Archimedes.

As a potential customer, I need your honest criticism, I am impressed by your ability to learn from others. I respect determination and humility more than bravado.

Give credit where credit is due and do exceptionally well.

Negative perceptions about software development. Do you have a solution?

Posted on by

Feedback on my proposed session at Agile 2012 on whether principled Agile practice is capable of creating workplaces and an industry more inviting of women software developers…

I could not agree more. There are many negative perceptions about software development these day in the US (off-shoring, hostile env, long hours, …). As a result, my friends at North Carolina State University tell me that overall CS enrollment is down. There was a similar event in Japan with the creation of the “Software Factory” in early 80s. I believe that they almost decimated their software industry. But how do we solve this? It has to start early as the career begins way before their first job. Leadership? If we want to maintain the industry, you bet.

Agile thought leaders came together in the first place to challenge the rest of us to empower individual contributors, elevate the role of craft and quality, cultivate collaborative ways of working, and create better, more valuable software products.

Following their lead, principled Agile practice is a determined process of honest observation and incremental improvement. It is dedicated, courageous advocacy for removing obstacles — an effort supported by analytics and a track record of improved performance.

The ambitions of this change don’t stop at a team or a set of engineering practices (though those are hard enough to accomplish). It is a change program within an organization.

We should see our mission is aligned with creating a software workplace and definition of the software developer inviting to articulate people, with diverse interests and points of views, who reflect our actual end users, and who want careers that have meaning and purpose.

I’ve never participated an agile adoption that didn’t ultimately set its sites on the larger company, the products that organization is building and why it is building them. I’ve never been part of a prolonged and dedicated agile adoption that didn’t bring developers closer to creative people outside the team, that didn’t make work a more rewarding place to show up each day.

Agile practitioners need to battle workplace cultures that discourage women and other talented people from entering and remaining in our field one dysfunction, one bully, one obstacle at a time, in one workplace at a time, because they are obstacles to collaboration and trust, disempower and burn out talented individual contributors, and distance us from our customers and end users.

I’m not saying this happens everywhere or that the changes are permanent. Widespread adoption brings with it mixed and often disappointing results. But enough of us need to drive for this change in enough of our shops, enough of the time that Agile remains a path to excellence for those of us capable of striving after it.

And by doing this we will create enough change to influence the rest of the industry. Agile adoption itself is an example of this kind of change.

Does this effort provide a clear path to success? Clearly not.

But is this approach capable of driving large and dramatic changes in companies and our industry? Yes.

An outlier to the outliers, observations of an agile practitioner at an academic conference

Posted on by

Molokini viewed from the Grand Wailea HotelI presented my paper “Agile Values, Innovation, and the Shortage of Women Developers” at the Hawaii International Conference on System Sciences #45 (HICSS) on Thursday, January 5th. I’ll publish out my presentation notes in this blog over the next week. I’ll also link to the published paper when it is available on the IEEE website.

A puzzling experience

I’ve presented papers at HICSS before. Mostly in the Agile track chaired by Jeff Sutherland. I did present once in a more purely academic Ethics track.

In this case, HICSS had two “Agile” tracks. And the one I submitted to was actually not Jeff’s track. Kind of amusing. But also kind of NOT as the real reward of this conference has been the mix of educators and practitioners. By having two tracks, HICSS split the audience. I was in an academic track with an academic audience.

I am a digression

As the whole topic of Agile is a minor footnote at this conference, I found myself an outlier to the outliers. Or as the chair of my mini-track at this conference called my paper, “a digression”.

I will admit it. My paper is a digression. It was off topic here. It would be off topic at a professional Agile conference. That doesn’t make it irrelevant and I’m grateful for the reviewers who allowed it into the conference and the people who attended my talk.

It is about what our industry and our peers do to discourage and drive away women from software development and how Agile values can help practitioners find the courage and focus to fight this. Like I said, I’ll start publishing out my notes this week.

Just another process

I should have realized I wasn’t proposing into Jeff’s mini-track just based on the title: “Agile Software Engineering“.

Just the use of the word Engineering will inflame the passions of many very good Agile practitioners. I am not one of them. I understand “craftsperson” and “engineer” are freighted concepts. But I am the son of an Engineer and spent over ten years working in theater while becoming a paid software developer. I know that both terms imply a love of disciplined execution, a dedication to excellence, a sense of personal responsibility, and a society of peers.

However, in this case the phrase Agile Software Engineering spoke to an overall tone of the day I’d summarize as, “Really, agile isn’t so different from everything else. It’s just a process framework. Just some practices that apply in some cases and don’t apply in others. A good developer will do good work in spite of the process they use.”

The heart of my concern

This is entirely true if you focus on the practices but this characterization of the Agile movement gets to the heart of my concerns about widespread Agile adoption. Agile adoption isn’t about the practices. It’s about the principles behind the practices.

If you don’t have those values instilled into your team and aren’t working incrementally to install those values into your organization. You can call yourself agile but don’t characterize your understanding of what that means as the sum total of what Agile practice represents.

I don’t claim “Agile” is the one answer

It is clearly possible to build a team oriented, collaborative organization without calling your values, Agile.

It is also possible to get through life without wanting to work on a team or to collaborate with anyone. Not every software professional can or wants to embrace these values or would be successful if they tried. And you can build decent software in such a work place.

I also know there are now a plethora of shops that promote their “agile” process that wouldn’t acknowledge an Agile principle if it stood in front of them naked. They don’t give a rat’s ass about their coders — they consider team formation an org chart decision and wouldn’t tolerate self-organization for a second.

My path

But I know after years of hard won experience that Agile principles are my path to an empowered, humane workplace capable of producing work I am proud of that delivers for the business and addresses the needs of end users without exploiting and disposing of talented individual contributors along the way.

So, yes, some agile practices may be a prescription that can be applied selectively. But “Agile” as in the set of values I go to work with each day and come home with each night? That is me. Not my toolbox.

A plea to my fellow developers and our employers [Harm]

Posted on by

water waveRevelations today about a security breach at Sony Pictures. If the claims are true, the company failed to take even minimal steps to protect the identities of their users. Passwords were stored in plain text.

There are many reasons why this happens: naive business sponsors, inexperienced or pliable developers, poorly thought out or narrowly defined requirements, lack of regard for user privacy, and simple schedule pressure that leads to mistakes and cut corners.

It is unacceptable to assume stored user information is not sensitive simply because your site doesn’t do anything sensitive with it.

People re-use passwords. They shouldn’t but they do. They may only be signing up with you for access to white papers but that username and password may crack facebook, paypal, capital one, or any number of other websites.

We can’t treat websites as something less than software, cram as many front facing features into them with as little time and investment as possible and expect a serviceable, safe, and usable consumer experience.

We can’t treat developers as disposable widgets that are there to “work hard” and “do what they’re told” and expect them to watch our back by behaving as ethical professionals and crafts people.

We can’t expose customers to this kind of risk and expect to retain them as customers.

The best way to encourage new and onerous legal obligations is to act irresponsibly because there is no current legal obligation to do otherwise.

There is a historical pattern. A new field starts generating significant wealth and the resulting products and services become widely adopted by society. As a result of that success, failure becomes more visible, more frequent, destroys more wealth and harms more people.

The industry, practitioners and the government step in to reduce the failure rate. The typical result is government licensing of practitioners and regulation of businesses, accreditation of training organizations, and professional bodies with codes of practice and certifications.

I’m not against any one of these things if they evolve gradually.

But if we create another “software crisis.” This time one that affects the safety of large swaths of society or the wealth creation their trust of the internet represents. Then these things will happen too rapidly, too thoughtlessly.

So, here’s my plea to product people and executive sponsors:

  • Realize software is complex and websites are software.
  • Hire experienced, thoughtful developers, encourage them to tell you the truth and LISTEN TO THEM.
  • If you take risks to get something to market, take the time later to circle back and invest to bring that risk down.
  • Don’t take risks that can harm your end users.
  • Realize a website is not a onetime upfront spend but an ongoing commitment of time attention and resources.
  • Realize if you intend to use a website for a short time or an experiment, follow through and dispose of it — or be prepared to invest significantly more in turning it into a long-term asset.

Here’s the plea to my fellow developers:

  • Take the quality of our work seriously.
  • Learn, learn, learn how to write good code.
  • Take our end users seriously. DO NO HARM.
  • Band together and demand the best of each other