Wednesday, August 5, 2015

Developers are not freakin' engineers - Part 2

(Part 1: Developers are not freakin' engineers)

#Agile2015, which I can only afford to follow from a distance, came up with what looks like a new meme: Agile is improv.  And there's more that supports my assertion here.

Having spent time on the improv scene, I think the comparison is apt.  I'm gonna play with the metaphor.

1. Waterfall developers are actors who are expected to learn their lines and deliver them regardless of what's going on onstage or in the audience.

2. Engineering:SW Development::Stagefighting:Acting

Stagefighting requires mad skills: it's a domain. But a great swordfighter/MMA fighter/etc. is not necessarily a great actor.

Some domains are math/physics/etc.-intensive. Developers who work in those domains need all those skills. But they aren't enough to make for good software.

3. Here are a couple of quotes from the conference:



"Agile software development is people-focused and flexible." - via @DanaPylayeva


"Software processes which separate out design and construction are fundamentally untenable, unlike building a bridge, building electronics, etc. [Fowler]

The manufacturing metaphor was broken from the very beginning. Assemply lines are optimized to produce many of the same exact thing. With custom software, you only ever build one." - via @GetzTweetz

People-focused, flexible, custom - these are aspects of software that are seriously distant from anything we associate with engineering.

4. Software itself is orders of magnitude more malleable than what engineers deal with.  We're essentially working with pure Categories, magical atoms of Platonic ideal forms.

5.  I've worked with engineers and physicists who fled their abysmal labor markets for development. They knew a lot about the domain, but next to nothing about software.  Don't get me started about the code I had to salvage....

Engineers are not freakin' developers.

Developers are not freakin' engineers.

Monday, August 3, 2015

Developers are not freakin' engineers

My current title is "Software Engineer in Test". I'm part of a QA team, looking for ways to improve their process. I'm actually writing tools for the dev team. It's a long story.

Anyway, I've had titles with "Engineer" in them many times in my long unillustrious career.

But I've never really been an engineer.

I didn't want to have to write this now. I want to go to bed so I can get up at 6 for my hour's commute. But I twote a hashtag and I think I insulted somebody, so I have to clarify. 140 chars won't do the trick.

The hashtag: #DevelopersAreNotFreakinEngineers.

Developers with any aspirations to Agility shouldn't want to be considered engineers.

Here's the beginning of an outline of what I mean:


  • Engineers can count on settled/established mathematics. Developers are barely grasping at the rudiments of the math behind what they do (best bet is Category Theory IMAO).
  • Engineers work in well-defined domains with settled/established natural science behind them. Some developers work in these domains, but I don't want to call even those developers "engineers". 
  • Developers deal in an infinitely more plastic medium than engineers.
  • Engineers are almost always members of BDUF/Waterfall organizations. The engineers that tried to stop the Challenger launch because they knew the O-rings could freeze were overruled by management: their expert opinions meant nothing in the face of deadlines/PR/etc.
  • Developers want to be called engineers because it's respectable. It's like wearing a dashing uniform.  It's professional. Maybe we'll get paid more....
There's more, but I'm tired.

Monday, January 21, 2013

The Incident of the Fumbled Phone Screen

It was a technical screen led by an architect at a company that billed itself as Agile.  We started out with a general conversation about good OO practice and Agile development.

Then he asked me about HttpRequest.  I described its general behavior, but I had the feeling I wasn't satisfying him.  It had been close to two years since I worked with a Java app that used HttpRequest.

Later the recruiter who had set up the screen called to say the interviewer loved what I had to say about OO and Agile and admired my passion, but felt I didn't give enough detail on HttpRequest, so they were taking a pass.

Monday, December 17, 2012

Asymmetric Lock-in

That's what I call a policy of certain agencies or individual recruiters whereby candidates are told that if they are sent on an interview they must commit up front to accepting an offer in case one is made.

An example of asymmetric lock-in (first item)

What makes this lock-in asymmetric is that the client company is never committed to making an offer in the interview.

This is problematic because one of the fundamental tenets of "free enterprise", as we are all taught from birth, is that the relation between an employer and a human resource (formerly a "person") is one of full equality and symmetry.  This is why unions are unnecessary, as we are constantly being told these days.

I can understand if recruiters are chasing commissions or points or whatever that they want some guarantees when they spend time on something.  I'm sorry, but there are no guarantees in this business:  free enterprise is about risk.  But I will guarantee that if I find out there's a policy of Asymmetric Lock-in,  I'm not playing.

Thursday, June 28, 2012

Michael Feathers has an excellent post on a hitherto unremarked value of builds, including this line:

Development is an attention-focused activity, and for me at least, a sense of closure is important for that focus and important for morale. 


And for me, this is yet another example of the critical importance of rhythm in the development process. XP is a hierarchy of rhythms,  from regular releases through iterations and daily standups down to the Red-Green-Refactor cycle.

But it's not just XP:  every developer who hasn't burnt out develops some kind of rhythm. In an environment based on an ideology like Waterfall that's seriously disconnected from reality, corruption is inevitable, and the developer's personal rhythm is not going to be good for the project.  I've run into this on my current project, which is "corporate Agile" - i.e., largely about daily standups. I've tried to convince team members with no real Agile experience that TDD is personally satisfying. Many of them don't buy it, not for intellectual reasons, but because it's completely contrary to their own rhythms, which involve writing a lot of code, building up the tension, and then manually testing it, which provides the release.  It leads to complex and overengineered code that's nearly impossible to create automated tests for.

I think Kent Beck's most original insight about development was that it's done by humans, not machines. (Okay, so it wasn't that dramatically new - Weinberg brought psychology into the methodology conversation, even if it was based more on an abstract ideal than a felt reality.)

Wednesday, September 21, 2011

What am I looking for?

I'm editing this post over time - it's in chronological order - latest last.

20110921:   I'm looking for work.  Here's what I'm thinking would be ideal (this changes because I learn something new on every project - I'll keep this post up to date):

A long term (contract or perm) engagement with a team working on legacy apps.  That's where the real challenge is - greenfield is easy.  I'm dead serious about this.  I know: every developer wants to get in on the ground floor of the next big cloud/social/multiplatform/HTML5/your-hot-language-here killer app.  Not me.  I do that at home.  At work I want a challenge of a particular type: the combination of technology and social interaction that is Agile and the jungle of legacy code.

Notice I say "team".  Ideally this would be a functioning XP team (if you think I'm talking about an old but still kicking OS, our relationship is already in trouble).  Or - better: a newly formed team in an organization that sincerely wants to go Agile and understands that Scrum is about management, not development:  XP is a Agile methodology for developers.

I recently had a disastrous stint with a company that did not understand Agile.  I was actually told not to talk to other developers about what I was working on, because they were "busy".  Right.  These folks misrepresented themselves as open to Agile.  They weren't - or more charitably, maybe they just didn't know. Oh sure, they had daily standups.  But in terms of development process they were mostly in the Cowboy/Hero mode.

As a matter of fact, I'm a terrific team member and mentor.  I always work Test-Driven (TDD and BDD) even if nobody else is, but I'm glad to show teammates how productive it can be - I gained some converts on the project I'm now rolling off.  (If you have a problem with TDD/BDD - again, our relationship is already in trouble.)

I am absolutely not interested in being an architect, QA tester, business analyst, DBA, Websphere administrator, etc., etc.  I'm a software developer:  J2EE, DotNET or Rails, frontend, middle or backend - ready willing to learn new OO or functional languages and frameworks and work in new domains.  (Of course, as an XP developer I have done all of the jobs above - as part of my normal development duties.)

Yes - I need to put food on the table and in bad times I take bad jobs.  Fortunately this is not a bad time.  But you'll have to be honest with me:  if you think Agile - XP in particular - is a bad idea, or it's being forced down your throat by Corporate and you'll show them!, better you don't even phonescreen me.


20110922:  Did I mention that I live and work in Chicago and will not travel or relocate?

20111011:  Kent Beck recently said a lot of what I'm thinking  in My Ideal Job Description.

20120609:  After a year as the primary developer on Northern Trust's highest profile application (Goals Driven Investing),  I've learned a lot about teams, code quality, process, etc. in a corporate environment struggling to become Agile.  One lesson: how quickly a greenfield app becomes a legacy app when ACPs (Alien Cowboy Programmers) are involved. Will be posting more on this soon.

20121201: Not much to add except:  TDD is non-negotiable.  I will not work in an environment that does not allow developers to work this way.  It's a matter of safety, both for the software and its developers.

20150212: Learned more about flexibility on my current project.  It was led by a developer (call him G) I consider a genius - no college degree,  self-taught programmer, cool, rational, well-read in Agile and modern OO concepts and a down-to-earth manner.  G had set the project up to use a kanban board - I had never worked in that mode, but it feels much more agile than fixed iterations.   

I think the coolest thing about G is that he has no fear.  After a zillion years in this business, I believe fear - usually unconscious - is the biggest obstacle to productivity and rationality.  Of course, that's pretty much what Kent Beck said.

G isn't into pair programming, which was too bad - we developed a tendency toward silos.  (That may have been caused by the rest of the team not having a complete and simple mental model of the codebase. G has the whole thing in his head.) But we did evolve a practice of handing off subtasks when a story turned out to be bigger than expected.  This is a form of knowledge diffusion that’s not as powerful as pair programming but much more organic and efficient than code reviews.

The success of the project led to G being picked up by the client as an employee, and gradually pulled into other projects.  I suspect this will lead to what Uncle Bob calls rot in the codebase, because no-one else has the complete picture.

Tuesday, July 13, 2010

Testing and Design

Just watched a great video - The Deep Synergy Between Testability and Good Design, by Michael Feathers.  Combining this with JBrains' blog post How test-driven development works (and more) and his video Integration Tests are a Scam would make an excellent intro to TDD, and maybe I'll get a chance to use it soon.