Journeyman Programmer

DECLARE
   tokenString      VARCHAR2 (256) := ‘Jim,Jerry,Jordan’;
   tokenLength      NUMBER := 0;
   tokenDelimiter   VARCHAR2 (1) := ‘,’;
   tokenChar        VARCHAR2 (1) := ”;
   tokenIzed        VARCHAR (30) := ”;
BEGIN
   SELECT LENGTH (tokenString) INTO tokenLength FROM DUAL;

   FOR i IN 1 .. tokenLength
   LOOP
      SELECT SUBSTR (tokenString, i, 1) INTO tokenChar FROM DUAL;

      IF tokenChar = tokenDelimiter OR i = tokenLength
      THEN
         IF i = tokenLength
         THEN
            tokenIzed := tokenIzed || tokenChar;
         END IF;
          –> DO YOUR INTERESTING STUFF HERE
         DBMS_OUTPUT.PUT_LINE (tokenIzed);
         tokenIzed := ”;
      ELSE
         tokenIzed := tokenIzed || tokenChar;
      END IF;
   END LOOP;
END;

DECLARE
   tokenString      VARCHAR2 (256) := ‘Jim,Jerry,Jordan’;
   tokenLength      NUMBER := 0;
   tokenDelimiter   VARCHAR2 (1) := ‘,’;
   tokenChar        VARCHAR2 (1) := ”;
   tokenIzed        VARCHAR (30) := ”;
BEGIN
   SELECT LENGTH (tokenString) INTO tokenLength FROM DUAL;

   FOR i IN 1 .. tokenLength
   LOOP
      SELECT SUBSTR (tokenString, i, 1) INTO tokenChar FROM DUAL;

      IF tokenChar = tokenDelimiter OR i = tokenLength
      THEN
         IF i = tokenLength
         THEN
            tokenIzed := tokenIzed || tokenChar;
         END IF;
          –> DO YOUR INTERESTING STUFF HERE
         DBMS_OUTPUT.PUT_LINE (tokenIzed);
         tokenIzed := ”;
      ELSE
         tokenIzed := tokenIzed || tokenChar;
      END IF;
   END LOOP;
END;

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 think it so funny.

The management, who are a bunch of PM’s, refuse to accept the fact that there is a difference between a developer and a tester.  And that there is any hand off, at all, whatsoever, between a development environment and a test environment.  No matter what the time line is they call it waterfall.  And we don’t want to do that, even if we’ve never done it before.

Of course some things are already waterfall, like requesting DB changes in DB’s I don’t own.  Or getting environments up from server groups I don’t manage.  Or gathering requirements from software still in development.  But really they are not waterfall . . . because PMs say so.

I am constantly shocked in the exchange of emails with the director, this failure to even recognize that there are the professions of BA, DEV, and QA — that we are all of equal skill in all things.

Here was the response I got, to a flow I wrote up for the highly inadequate Agile application called Rally:

Journeyman (trying to be nice):  “A lot of times we
forget that while in Agile its true everyone is doing things in parallel: req’s
gathering, dev, testing  . . . .the lifecycle of a story is still kind of linear
reqs->dev->qa.  So even though I may be gathering reqs on an Allergy
story, be developing a staff story, and testing someone else’s ACL story today, each of
those stories still have their micro-flow outside of the people.  I refocused
our scrums to track stories because that’s what (I think) the business really cares
about  .. not my status, but a story status.“

Director:“Is there a way to reduce the linearity for some User Stories (e.g. have the BA
look at code on your PC during Development to avoid surprises later, grab QA
frequently to step run their test cases on the code on your PC, etc.) to squeeze
rework out of the cycle?

So there it is

Agile to these people means that there is absolutely no flow whatsoever.  No professions, no expertise.  No states.

I would assume that a BA would be mostly done with the requirements by the time I code it.  But the management thinks the BA can code it.  The QA would assume I’d decide — OK test it I’m done.  But not in this new world of PM’s who have strong opinions and no experience what-so-ever, ever, of developing software.  None.

We could be doing QA->DEV->BA, or DEV->BA->QA tasks who cares its all the same at the same time.  I can write software before I get requirements.  QA can test with no code.  BA’s, well, they aren’t needed who needs domain experts???  Just avoid waterfall.

I put this forward

After a lot of discussion with the management team I put this diagram forward as a process for parallel everything which = true Agile.  Management LOVED it!!  It shows the true parallel nature of software development.

Look familiar?  Hope you have a good laugh.

Yeah that’s right, the management agreed to WATERFALL method.   They just call it Agile.  Hahahahahahahhahahahhaha! 

I am so happy that the world of people who barely do anything, project managers, have taken over Agile from the people who invented it, development teams, to make life a living hell for all.

My current job as developer involves not development, but instead project managing my scrum team of 5-7 people while the project manager filths up his knees polishing Rally’s knobs, a duty he relishes, and the director sits around all day reading first page Google searches about Agile and prepares long and extensive lists about who to blame for his own failings including the project I am now part of.

The new Project Manager version of Agile has in short added MORE managers to the process of delivering software, and put more roadblocks in the way of getting software written.

An actual discussion with the director of this department and myself went like this:

Directorum: “I expect all software to be delivered, tested and all, by the end of the sprint.  I want everyone testing.”

JM: “OK no argument don’t know why you are saying that.  BTW thanks for doing release planning two months into the project, good job.  We’ll have to scale back on our new development estimate hours by probably 25% per sprint to accommodate this new definition of a sprint.  We can’t develop new software and have it tested on the last day of the sprint if we aren’t going to overlap the QA and DEV timeframes.  Fewer stories from what your BA’s have been dumping into the backlog.”

Directorum:”That’s bullshit.  You can develop up to the last day.”

JM: “But how can the sprint deliverable get tested by then?  What’s the cutoff?”

Directorum: “Everyone tests.  QA, Developers, everyone.  The only thing separating a QA from a Developer is that the QA doesn’t usually use Java.”

JM: “You’re kidding me.  (Looks at QA lead).  Donny do you know how to code Java applications in Eclipse?  What about Flex, or GWT?  How are your Oracle chops?  Can you teach me how to use Quality Center and write test scripts?”

Directorum: (Getting visibly angry) “Everyone tests.  Everyone does regression tests.  That’s Agile.”

JM: “OK it’s your dollar.  We will all be generalists.  I’ll assign QA tasks to developers  when we get there,in the mean time I could use another developer I’ll assing Developer tasks to QA.”

blahbitty blah blah

Meanwhile, the company pays big bucks for developers . . . assigns them QA tasks.  Thus negating their need for decent developers and thus going against doing things in Agile fashion.

How did it get to this point?  What happened in the last few years that developing became this unpleasant job of micromanaged task execution?

The Observer Effect

There’s an idea in physics called the Observer Effect.  It states that the very act of observation changes what it is being observed.  Part of this is due to the measurement tool . . . for instance, and Agile tracker like Rally, Version One, or Mingle (the last two being best of breed software).

My theory is this:  people don’t like to be micromanaged, they life to be trusted.  But in the evolution of Agile developers have created a monster — a tool that project managers can use micromange their activity down to the minute.

The sum is this:  micromanagement, which changes the behavior of an employee in a bad way, has been implemented and is contributing to creating bad software by changing the behavior of developers who are now acting not to produce better software but to look good in a micro-tracking tool like Rally.

Modern Agile makes its developers accountable for how they report in a micro-tracking tool, but not for producing better software, by changing the priority of a team from delivering software to that of promoting a project manager’s career.

What is wrong with today’s Agile, and how to fix it

What’s wrong with Agile:

• Agile has been heisted by people who are not in the process and do not understand the process: project managers.
• Usually things on an Agile project go wrong with two things: training, and release level planning.  Both of these are PM duties.
• PM’s are usually the ailing point in Agile because they wield power and use it to immediately hold people accountable for their own failures instead of doing their jobs.
• Training:  the most difficult piece of Agile is learning to write codable, testable stories that can be accomplished in a sprint — a training problem.
• Most tools like rally are micro-blame tools.  They completely ignore real release processes and turn Agile into a 100% report up process contributing nothing to building software.

How to fix it:

• Designate someone to lose hours of their life protecting the team form the psychotic PM-oriented Agile up process.
• Use another process in parallel with the process that’s in the way.  Many teams have done this often: use a process that works, and report on the process they tell you they want.
• Go simpler.  Use a kanban board or lean or something, and report your status directly to your BA’s/stakeholders.  Make them happy.
• Get your tooling in place, i.e. testing tools, ci servers, bug tools.  Get them in place that’s the good stuff from Agile.
• Adhere to the simple things Agile took from the old XP practices: small iterations with deliverable software.
• Hold management accountable by logging everything you do for time in their chosen report up tool.  For instance, I now have per-sprint PM stories and I log all my PM tasks against that while my PM polishes sales people’s knobs.

Be patient.  Things will change in a few years.

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;

QA Folks are a fine, fine breed.  They have the tremondous task of being the front line of blame for software quality; its a dubious responsibility.

As such, I do not think that they are the right people for being a scrum master or development team lead.  They very simply do not know how to build software, its not their skillset.

Some idiot morons decided during this Agile revolting-lution that developers and QA are the same thing; and their delivery of a piece of software is the same thing.

What the fuck?

Let me reiterate:

What the fuck?

Today in Rally I chuckled, because they (meaning Rally) has decided that the DEV/QA one status to rule them all of “P”rogress was sufficient, and thus they train their PMs.  So when all of our developer tasks were complete, I explained; “Hey we (DEV) are done but not QA, but you can’t tell from Rally because it doesn’t handle the handoff between DEV to QA, that’s on our whiteboard.”  Riiiight.  back to the kanban board my friends.  I could hear the PM fuming over the speakerphone.

Pairing? Really?

Once I saw a video on InfoQ about how QA was “pairing” with developers during software development during nightmarish TDD process.  What was scary was that the lady in the vid had the type of attitude that makes developers cringe:

“Developers are out of control cowboys that need to have tabs kept on them.”

I mean, WTF.  The ole’ “Keep them in line and on track” mentality.  Great.  I dream in inverse data cubes and you think I am a unprofessional.  It’s  like having a critic sit there all day with nothing to contribute but bad feedback.  Someone, please, tell me that bad processes produce quality software. Even at a giant health care place the VP (ex-qa, may I note) described this same “pairing” activity.

I’m sorry, but its NOT PAIRING.  Frigtards.  QA can’t code so they are bringing NOTHING to the time spent with the IDE.  Unit testing is out of scope and skill for QA.  Jesus.

Go and write up up the traceability matrix of user functions like you are supposed to.  Christ the weak point, and expensive failure point is ALWAYS the regression test, QA’s realm, and Agile has them sitting with developers dictating bubble sort unit tests?

Not in my company.  This is just another example of Agile’s abuse of trust amongst employees via micromanagement.

A real nightmare

Years ago I worked at a big, giant company that manufactures all things two dimensional.  We had a PM with a QA background inflict the nightmare of nightmares on us:  they decided they would test on our development servers and log bugs.  We would spend half the day explaining and writing up how we weren’t done with the piece they were writing bugs on.  Then, the testers would report on how many zillions of bugs they found.

Serious.  In fact it got so ridiculous . . . a few of us were using Homesite and others Front Page for some HTML editing due to developer preference;  and the manager went off the handle: “we aren’t building a Front Page app!!”  We laughed out loud at her.  The newbie said “uh, yeah that’s just an editor like Word or AmiPro . . . its HTML, not Front Page.”  This crap went on constantly.

Riddle me this

Developers are a good lot, we know that in a sane process QA is interfacing with the BA’s and is our line of defense against us doing something super stupid.  It’s great.    We love having QA buildmasters that we hand our scripts to, then they can build and build and leave us alone.

But what has made QA design and architecture experts just because TDD came in on the scene?  They have this idea that Testing is the World: The world exists to get things into Testing. It’s horrible . . . people who don’t build software dictating design?  I absolutely do not understand it.

We are not building things to test.  We are building applications to do cool things to make the universe better.

It’s funny, way back developers used to have that same attitude; that the business solely existed for our need to make cool software.  Now, QA takes over those reigns of instanity.  I wonder if a role/responsibility change has happened . . hmmmm . . .

Gee people who don’t build software dictating its design . . ya think that just might contribute a tad bit to bad software quality???  WEEEEELLLLL?

SM – DEV and QA are separate processes

QA being scrum masters over developers is an unfortunate choice.  What about DEV over QA?  Not much better; a bit better,  but each group has a separate process outside of their respective tasks.  In either case, the SM is out of their element and more importantly Can’t Remove Impediments for the practice group.  Developers at least have a bit more chance from a technical standpoint to help out QA on the build servers, DB deployments etc.  But I noticed that the questions from QA SM’s are usually in the realm of an accusation, not a git-er-done mentality.  STOP IT.  When BA’s, QA’s, and PM’s scrum master for developers they oft become impediments.

Luv Ya!

QA, I love you.  I’ll help you out.  I’ll be above the board with you.  We need you.

But please remember: developers operate in a different universe than you do.  Like sitting here at one in the morning on a work night writing this up.

I am not a proponent of TDD, but I will admit it has its place.  And sometimes that place is not to use it, if the ultimate outcome will be of less value to the purpose of your software.

Some reasons not to use TDD if the conditions warrant are:

• More code is higher risk for bugs.  Bottom line.
• More expensive.  TDD translates into stories/function points/developer time.  I don’t care what anyone says, I still like TAD a little better to get repeatable regressive costs over time.

Use TDD if you are designing things that will benefit from it.  Don’t if it will not.

Object Design?

TDD is a design pattern, nothing more nothing less. While I have read a few books about TDD . . . I wonder, if true TDD people refuse to do up front object design.  The methodology demands refactoring; and therefore following a Fowler idea that design will emerge, TDD practitioners must let objects emerge via refactoring.  I mean, if they are TRULY doing TDD that’s what they would do.

Timeboxing is Agile’s David

Its an interesting experiment to me; I do refactors and look for patterns.  Then I pull them out if needed.  Unless I come up with an estimate, and the project deadline and my manager says “no way jsut build it quick.”  If you get on one of those projects using TDD (I was on one) a LOT of spaghetti code, with lots of test cases, gets written.  Its about as bug proof as any other design style, that is, in those conditions TDD brings no value.

I think its a failure of a lot of Agile methods . . . ignores the reality of timeboxed projects.  I have never worked on anything but; even being relatively young as my first computer class was on a Tandy PET and my first Basic program on a Vic 20.

A Use Case Where TDD would Fail – SUV Analogy

I am actually using TDD do do some PL/SQL conversion scripts right now.   I have to do it old school; and its taking time.  Sometimes I just write the conditions.  Since the scripts are throw away it we can’t store the unit tests in any sort of DB repository (but that would be great for stored procs etc.).  I ran into a bit of a problem though . . . that writing code in TDD style sometimes causes more problems, depending on what you are trying to accomplish.

Talking with a friend I came up with this real-life analogy of where TDD would fail.

TDD thinks it addresses quality but one thing it introduces is possible defects  due to itself.   You have to make a judgement call based on your input factors of time, money, and risk as to whether its worth it to use this design pattern.  For example, it would absolutely be worth it if designing space shuttle software.  And, you had an unlimited budget.

But here’s an analogy where it would fail:

Suppose you are designing an SUV for extreme conditions.  In one case, it’s a highly wet cool condition and in another, is a hot temperature condition.

The designers decide that testing of everything is very important.  So they design in a hole in the engine that let’s you test sludge buildup in one of the cylinders:  you unscrew something and get a physical look.  Basically, a test has become part of the design.

But now the cylinder head is weakened because of the test.  You have introduced a few failure conditions:  possible weakened gasket that will let in contamination and cause engine failure.

• In the wet condition this may be worth while.  Sludge buildup and moisture may be something causes buildup and there would be value to check the state of the cylinder periodically to make sure you don’t need to run a cleaning process, etc.
• But in the hot condition, the gasket could keep failing and contaminants could be introduced via the testing port.  The strategy is just follow a maintenance schedule (TAD – test after), which you would have done anyway, because everyone has to do maintenance.

It’s just a hypothetical but there are a ton of other things in our life just like this.  Vehicles are easy . . . even now they are building all kinds of testing into the vehicles as part of the design (TDD): emissions, mixture, electric etc.  The payoff is that this is very expensive to pay for, and also in increase costs due to specialized maintenance because your every day Joe or Jane auto mechanic can’t work on their own vehicle.  Do vehicles really last any longer?  I’d argue that they do not.  TDD just extended the period between maintenance’s — i.e. you paid for your time up front instead of over time.

I’m not motivated enough to throw away a methodology if it may be useful, and TDD can teach us some things, but I guess the mantra is:  “TDD: do it only if necessary.“

Some developers have chosen to become true consultants.  I am one of them, for now, and I got here by default.

One thing that becomes glaringly, glaringly obvious is this truth:

Consulting companies and their recruiters are not your friends, they are salespeople.  And they are selling you a work contract for a fee.

That’s the bottom line.  A lot of recruiters hate it if I say this to them.  They want to be my good neighbor and then take my rate for a ride.    Thanks, neighbor.

Don’t get me wrong: sales is just as important as what we do in the process.  Maybe someday online sites will replace them but I doubt it.   Human contact is just too important.

One trend I’ve noticed in the last few years, especially with the advent of the assembly line PM methods, is that recruiters are getting quite nasty and treating a lot of people with a huge amount of disrespect.  Personally, I keep a list of interactions between with them (my are just notes but you could use Sugar CRM or something if you want to get fancy) .  I won’t write up on particulars EVER because everyone learns, makes mistakes, get’s better or worse.  But its nice to know who you can work with, and who not.

This article is more about what attitude to have toward recruiters, and how to manage the relationships.

Especially this has been a nasty year with the recruiters, here are just a few of my own experiences in 2009:

• Being submitted to projects without my consent (this can actually keep you from being submitted by another company
• Telling me they would lose their job if I did not take the gig.
• Clearly using me to fill  a call/contact quota to justify their job.
• Having recruiters inexperienced in my domain ask for a bigger cut than experienced recruiters in my domain.
• It happens to all of us: never following up.  This year far worse than ever.
• Being told to my face that I would get paid for 40 hours of work, but would be required to work a minimum of 54 a week.
• Scream at me because I would not give them my rate when no job was to be had (clearly, info gathering).
• Presenting contracts that are in opposition of my state’s labor laws.  In this case, because the rates had bottomed so much, they work trying to get people to commit for a year at shitty rates knowing they would rise and people would bail.  We have at-will in my state: means, you can quit whenever you want.  (I hope THEY got what they deserved.)

There are of course good recruiters and I know some.  It’s like anything else.  But just remember: recruiters are not your friend; they are trying to make a dollar.  They are your partners in business.

Guidelines I follow when working with the consulting companies:

• Treat the recruiters formally and with respect.
• Be ready to walk.
• Always get copies.
• Don’t let them photocopy your personal ID’s or even leave the room with them.  In my state it’s against the law.  Identity theft problem.
• Copyright your resume.  It could be useful if they use the data off your resume in a bad way.
• Don’t sign or agree to anything you do not like.
• Make sure you have a way to bail on a bad gig; do NOT leave it to the recruiter.  They’ll tell you “I pull my people out immediately if it get’s bad.”  BS.  They want you in there to make cash for them.
• Do not sign or agree to anything that is against labor laws there to protect you.
• make sure they are doing THEIR work you are paying them for: check issuance, HR stuff, on-site management etc.  If they aren’t, get out.
• If they invite you to lunch, go.  Play it cool though.
• Keep a small journal of your interactions with recruiters — don’t EVER publish or share it though.
• You should be journaling at work too — for things that happen like change in scope and agreed duties.
• You are under NO obligation to give out contacts of any sort, they are yours.  Keep them to yourself; they are valuable to you, as valuable as their own contact list.
• That $2000 they “give out” for a new recruit?  I have never seen that happen in 2o years.
• You trained yourself, you are bringing your experience and talents, and they did not build those.
• You owe your allegiance to your developer buddies first.   Look out for them; you will get on good projects and find work faster through them than through recruiters.  Your day to day life is with them; they are the people you are spending time with.
• Try to build a nice relationship with the recruiters.
• Be a good product.  You are their product to the site.
• Remember its YOUR life.   To do what YOU want.

I hope these guidelines help.  Now get out there and create something!