Recently I was helping out a team that was on a death march.  They had all the great things a high energy project requiring dedicated developers employs into the project methodology:

• Unpaid overtime, lots of it.
• Moratorium on vacation time – none allowed.
• Vacation time does not roll over at year end.
• Mandatory weekends and late nights.
• Short notice on certain late nights, as much as (gasp) four hour notice for having to stay late Friday or work Saturday-Sunday.
• Zero, ZEEEEEE-RO, project plan and schedule.

You might think this is crazy.  I am thinking that this is more likely the rule now rather than the exception; I’ve been talking to my colleagues and all of us are having this problem:  poorly planned projects intent on destroying our outside lives; the reasons many work in the first place gathering cholesterol in their ateries by sitting still in place for 8-12 hours a day.

XP addressed this by calling out for the value of  “sustainable velocity.”  It did this by allowing developers to gauge their NORMAL velocity via estimates, and then to use that to predict the amount of software they could do in a short iteration.

Recently I was asked — “golly Journeyman if you are such a great developer then why is amangement never happy with the work?”  It’s because managment only wants one thing — to paraphrase Jackie Mason:  MORE.

Now I am not going to blame them but at some point we have to ask ourselves the simple question that if work is so great, why do they call it work?

Note, I am not saying don’t love your professions or what you do.  By all means do it.  But recently I was pitted against a another less experienced developer.  He billed 38% more than me — 55 hours to my 40.  He made roughly 2/3 as much per hour.  I produced twice the software with 1/5  less bugs.  The bugs took up an average of 50% of the time of the original story (due to requirements).  (This is all from a project tracking tool.)  So, in simple math it took him 110 hours to produce the original software, if we even out the bugs ( it wakes him 4/5 more to do the bugs thats 50% time 110) then it takes him 165 hours to equal my output.  Multiply by 2/3 the pay, he costs 109 hours in my dollars. 273% more expensive than me.

Management though only looks at hours on certain projects; not quality and planning.   So, a person who works more hours is of course more productive — in the new PM Agile world.

Now last wek I was at an Agile conference, and one of the vendors helped me figure out — the change was when Scrum came along. Like in 2007 it made Agile widely adoptable to management — SCRUM did this.  And in Scrum, with a tracking tool that many companies now use like MS Project manger — hours are more important than results.   Estimates are used against developers as accountability, instead of as an aid to get better estimates.   It changed EVERYTHING.

Sooo . . . anyway all my musings aside is why, young or old grasshoppers, we should avoid projects that say “High Energy” or “Want Dedicated Developers.”  Because here are the formulas to calculate the meanings of these terms:

High Energy Environment = poorly planned requiring lost of unbilled hours by task people.

Dedicated Developers = developers willing to work tons of extra hours for free.

Its as simple as that.  I am not saying don’t work hard.  I am just saying, work smart.  You will be taken advantage of if you don’t, your life will become miserable, and your productivity will drop.   70 hours of a burned out developer’s time with 30 hours unpaid on a meangingless project is way less productive than 45 paid hours of a developer’s time on a well thought out, superbly executed project.

And remember — management are negotiators.  Sales.  Compromisers.    They have to be because they work people jobs.  But its up to us to call BS on them:  poor project plans are not negotiable.  Life sucking jobs are not negotiable.  The way to stop the machine, is just to take your toys home and don’t play with them.

One thing I love about Agile is the amount of time spent in meetings.  Lots.

On many teams we instituted a “no-afternoon” meeting rule too.  There are stats that will tell you even a single IM interruption will take up to 25 minutes to recover from (you’d better look that up).  These days our Shift Foremen really like to see our green light on and ask us “is it done yet, is it done yet??”  Imagine how much time is wasted.

Well honestly I (OK Gary-O just came on — “here in my car . . . “)  uh uh honestly the one thing I can prove now, this moment, is the waste alot of organizations go through with these meetings due to poorly prepared management.  And right now I work for one of those.

Very plainly, the meetings are always late, and usually run over more tham the time alotted and solve very little.  Weekly, we have at least one big meeting with several DBA’s, a few developers and a few QA.  This manager’s meetings always run late, 15 minutes minimum.    So, eight people times 15 minutes is two hours wasted per week for the big meeting.

Then, there’s the daily and that’s usually late and overruns.  Since this meeting doesn’t start on the hour, most of a half hour is a wash.  Anyway, every day another 15 over/under times eight people = 10 hours a week.

Conservatively, 12 hours a week is wasted by this manager.  In month, that’s 48 hours.    If  this person is  there 50 weeks — the waste is 15 weeks of peoples’ time, almost 4 months.    Doing “Agile.”  And that’s not counting all the extra things that happen due to the daily interruptions.  We aren’t talking about team bonding etc.  We are talking a person who is poorly prepared, runs late, runs over, and is disrespectful of others’ time.

Now, most of the Huge Company, Incs. hire mouth breathers that need to be told exactly what to do.  Also, the only place a lot of incompetents can hide is in the large hiring crowd of Huge Company, Inc.    So time suck is unavoidable just by the stereotypes.

Wow.  So next time you buy that . . . whatever . . . imagine if 30% of the cost was due to a manager living the fast paced life of time suck.

Last year I was working at Huge Company, Inc. and they were trying to implement some agile.  I was brought in as one of those stack lead developers — domain, UI, smile, do a jig etc.  But soon I found myself leading two development/qa teams and kinda of a nightmare on my hands — top-down agile.

You see what would happen was this:  we (doing scrum method) would add our agreed stories to our sprint, start working, and about halfway through a big wig would come in and tell us to drop everything for one of their quickie projects.  This happened several times and we could never get our sprint goals done.  Worse, all the big wigs were going to agile training and still missing the whole point; and none of the task people were getting any training at all.  I wasn’t even allowed to set up our own training time if I wanted.  And we couldn’t get resuources like even regular meetings rooms — at times we’d scrum in stairwells.

What do you do if you are ordered to march agile, but they won’t let you actually do agile? Well this isn’t anything new — it has happened with all the project management styles I’ve been through in all Huge Company, Incs. I’ve been at.  Agile — does not offer a solution for this it is only a software building technique and that is all.

Well, if you are doing waterfall, rup, any ISO style or any other equivalent of agile you know you are up a creek and here’s what I do:

• Allow the leadership who is putting your team into these situations to be accountable for their decisions.
• Wait it out.  Unfortunately many times, especially with non-selfevident methods like agile, no matter what you say nothing will change until others get it themselves.  People have a funny propensity for continued thinking in a box and you just have to wait.
• Don’t struggle and argue,  don’t complain.  Give the paycheck writers what they want.  They may not want timely good software.
• Since you probably know that they really do want timely good software, do what you can in prep.
• Don’t work overtime for crappy underplanned goals.  Failure at the start of agile is imperative for gathering velocity metrics.
• Learn how to report to the big wigs in the agile tool, set up someone, usually the scrum master, as the cock-block to  management and let the task people get their stuff done.
• Don’t let your life go.  Don’t work huge overtime.   For some reason modern agile put its roots like XP in the crapper — don’t do it.  Everything you do outside of work contributes also to who you are at work.   It’s important.
• Track EVERYTHING.  For instance, your starting sprint snapshots.  Make sure all docs are in a version controlled repository even if you have to give the BA’s access to a folder in your code repository to do it.
• Be innovative.  Most times the control freaks will try to get in your way but just do it; developers are creators.
• Again — be patient, do what you can, and wait it out.
• You can always quit too, if its driving you nuts.  I know a QA/build master guy who was ‘totally agile” and it drove him nuts so much that all the developers weren’t doing TDD 100% of the time he had to quit — and he was happier.
• If you really feel strongly about, say “we need Hudson” then mock it up on a system and make a power point and show them the ROI.  If they don’t bite on it, present it to a weekly group and use it on your resume, Knowledge is always win-win.
• Patience.
• Be happy.

The bottom line is, yes, its all about the money and the target of agile tooling and methodology today is not the people who will carry it out but instead the people who are going to pay for the enterprise licensing.   Its just reality.

Here’s my recent example.  We just changed radically changed domains on a 10 year old code base;  its an DMU design (down middle up) — and the objects in the app do not in any way reflect the new database.  We were forced to bastardize the objects to deliver functionality based on what the sales people and management promised.

I ran the numbers — all the indexes, metrix, class relationship charts, analyzed stories and bugs  etc.  showing how brittle our domain code was and the dangers were were in (to change one class meant a physical change 100 other classes; giant huge SQL queries etc.).  The architect and management wouldn’t buy it.

So — all’s I could do was wait.  They had to see it to believe it.  And they are.  I didn’t get my panties in a wad, I wasn’t trying to introduce the newest version of “whatever” — just do a badly needed oil change.

The hardest and most important quality for creative developers to learn is patience. There is many times a bigger picture than what’s sitting in your IDE, right or wrong.  Just be patient, and keep your own box open for improvement.

If you’ve ever had to work on a legacy application with a HUGE code base, you might get faced with this situation:

Manager: “Hey journeyman can you fix this address on this page so that it knows to take a system configuration?”

Journeyman:  “Sure, give me a second for an estimate.”

You find the code:

public class AddressService {

      public String getFormattedAddress(Datasource ds, int yourFormat) {
           if (yourFormat == 1) { /* do this format */ }
           else { /* do this format */ }
           return addressString;

         }
 }

Now go in and track down the code to change .   Hmm interesting function called getFormattedAddress().  Let’s see, before I touch it do a code search in Eclipse : used in 147 places!!!!!  Ugh . . .

You shan’t dare change the function call in ALL those places, nightmare, just for one of the calls.

So here’s one way to do avoid this messy situation:

1. Add a new property, yourConfig, with getters and setters.
2. Override the function getFormattedAddress so that it takes your new parameter
3. Set that parameter in the overriding function.
4. Modify the original function to check the parameter, using a default if the value is empty.
5. Call the original function form the overriding function
6. Don’t forget to reset the default value!

Something like this:

public class AddressService {
      private String yourConfig = "";

      public String getFormattedAddress(Datasource ds, int yourFormat) {
           String localConfig = 
                   (getYourConfig == "") ? "default" : getYourConfig();
           setYourConfig("");   
           if (yourFormat == 1) { /* do this format +localConfig */ }
           else { /* do this format + localConfig */ }
           return addressString;

         }
     public String getFormattedAddress(Datasource ds, int yourFormat, String inYourConfig) {
           setYourConfig(inYourConfig);
           return getFormattedAddress(ds,yourFormat);
     }

    public String setYourConfig(String inStr) {this.yourConfig = inStr;}
    public void getYourConfig() {return this.yourConfig;}
 }

Now you can call the function from either its original state, or, pass in a config.
				

I read articles on Tech Republic from time to time. They’re . . . . OK. But I don’t remember signing up for this kind of email notification. You’d think a self proclaimed tech site would show a little more ethical behavior. Just goes to show you, their opinions are motivated. Here’s my recent inbox. WTF.

I had to write an Oracle script template for work to kind of create a guideline for our developers since we are getting inputs from ourselves, DBA standards, and business requirements from our BA’s and customers.

Anyway, one thing they wanted was batch commits . . . so I wrote this quick little piece:

It creates a temp table, populates it, and puts a DBMS_OUTPUT line for whatever number I set the commit at . . . pretty self explanatory.

CREATE   GLOBAL  TEMPORARY TABLE temp_Cursor_Count  (
testNumber Number(10)
) ON COMMIT PRESERVE ROWS;
commit;

DECLARE

curVariable Number;

cursorCount Number(10) := 0;
cursorCommit Number(10) := 1000;
cursorMod Number(10) := 1;

CURSOR tt is
select * from temp_Cursor_Count;

begin

–populate temp table
For i in 1..9999
Loop
insert into temp_Cursor_Count(testNumber) values (i);
end loop;
commit;

FOR record_tt IN tt LOOP
–INITIALIZE Cursor values
curVariable      :=record_tt.testNumber;

cursorCount := cursorCount + 1;

select MOD(cursorCount,cursorCommit) into cursorMod from dual;

if cursorMod=0 then
–Normally this is where your COMMIT would occur.
DBMS_OUTPUT.PUT_LINE(cursorCount);
end if;

END LOOP;
end;

truncate table temp_Cursor_Count;
commit;
drop table temp_Cursor_Count;
commit;