Fighting the Good Fight

It's actually been a good week for me - I've spent most of it actually writing code.

The big thing that I did was spend 30 minutes arguing with a project lead about our new API.  We are putting a REST interface over an older one, and I was arguing that we needed to make the REST one better than the older one. 

It does nobody any favors to do a dumb port of one interface to another.  Each type of API has strengths and weaknesses, and they rarely overlap.  So I was strongly advocating that we eliminate the useless artifacts required by the older API.

The part that was unsettling was that the project lead was not mentioning any reasons for shortchanging the port.  I have often had a manager tell me that there was not enough time to do something differently, and in some cases that is a valid concern.  But that did not come up in this discussion, which worries me.

Just a small clarification on the blog

Not that I think the readers need to be told, but just in case.....

My nom de plume "Dixie Software Ninja" is not in any way related to the current (2015) controversy over the use of the flag of the Army of Northern Virginia.  I use it solely as the geographic term describing the Deep South (southeastern USA), where I currently live.

(And it's my 200th post! Yay me!)

Reach out and touch someone....

I now know why Agile recommends that the entire scrum team, if not the entire development team, be co-located.

So you can walk over to the desk of the programmer who wrote code that accesses a database row, loads in all 8 columns from the DB layer into local variables, AND DOES NOT SET THE OBJECT FIELDS FOR THE LAST 5 COLUMNS OF THE ROW, and slap them upside the head.

Or so you can look over the cube wall at the programmer who was tasked with writing a C SDK so your existing applications can perform one operation to get some data into your Java ecosystem, AND FAILS TO SET HALF THE VALUES ACROSS THE INTERFACE, and dump your coffee in their lap.

Seriously, The Job has led me to believe that the offshore teams are just interested in meeting the most minimal definition of the problem they can to get past something they think is no longer a useful part of the new, cool system.

IDEs and doing it all by hand

Recently I've moved to new project the The Job, and into the 21st century with respect to development environments - Eclipse, Subversion, Maven, But as I am learning the ropes for this new stuff, I'm finding a curious lack in what is considered state-of-the-art.  There does not seem to be any way to collect a set of actions into a bundle for repeated use - no scripting.

I'll wager I could write a set of scripts that would give me all the necessary functionality that Eclipse is providing, AND be scriptable so I could build on it as I needed

Giving a little Notice back

Not too much going on that I am able to post about at the moment, but I wanted to share out a little notice - I found out that Dustin's blog mentioned my post on developer passion and its pitfalls not long after I wrote it.  SO let's give a hearty "Hello!" to Dustin,everyone!

Third Time's The Charm?

So the Big G contacted me recently and it seems I look good enough for another round of interviews.  Maybe this time I will be deemed worthy?

============
update, much, much later

I was not deemed worthy.....:(

Surviving the Transistion to an Agile Methodology, Part 2

So your organization has decided to go Agile, and everyone is onboard, and you've started holding Scrum meetings, and coding in sprints, and everything's going to be just fine, right?

For Sale:  One bridge in Brooklyn

One of the biggest problems is the tendency from members of management to decide that "just this once" you need to circumvent the Agile rules, and (add work to the sprint in the middle|work without a Product Owner|pull your one expert on Technology X "for just a few days")

There is usually one manager who continually subverts the plan.  S/he will never say they are not doing Agile, but they will never really get with the program.

On the flip side is the manager who is perfectly fine with doing Agile development, but wants the metrics to keep improving, since they will be measured by the metrics, even if the metric is explicitly not a performance metric (like team velocity).  So this manager will be gaming your estimates so that their team looks like it is always improving.

Another pitfall is the gradual falling away of the sprint planning rules - that the team should make the estimates, that the stories need to be broken up into tasks, and that tasks should be self-assigned.  You gradually see managers trying to re-assert their traditional roles and hand out work based on their own ideas of effort.

Finally, the big Agile-slayer might show up - field support.  Nobody knows how log it will take to handle field issues, because the level of information can vary greatly.  Often you have customers that have political agendas keeping them from giving you good info, or sometime it's just really clueless support people.