in

 

AgileJoe

Answering all world issues with, "...it depends..."

Consultant Frustration Coefficient

Talking to Joey B this evening about creating a tool that would measure how frustrated you may become with wanting to mentor a team on Agile development practices. I am calling this the Consultant Frustration Coefficient.

What you would do is hand out a short questionnaire that would ask varying questions to assess the client’s value system and the staff’s literacy level as it relates to development pragmatic practices.

The result would look something like this:

  • Code: Staff shows a firm understanding of claiming to know OOP however certain frequencies indicate that staff view OOP as COBOL syntax with many function libs. Caution should be taken.
  • Design Patterns: Staff shows understanding of design patterns relating to UML documentation. All indicators are pointing towards an automated code creation and wizard driven setup culture. Caution should be taken.
  • TDD: Staff understands what Unit Testing is but does not understand why they should write test that QA should be writing. They do not want to use open source libraries. Critical deal breaker here! Extreme Caution!
  • Paired Programming: Staff indicators show extreme frustration with one another and would rather work alone in their cubicles on development task. Caution should be taken.
  • CI: Management indicators show reluctance to increased time spent outside of coding and server setup. Good luck getting it passed management. Staff may show resistance. Caution should be taken.
  • Agile: Staff has the probability of buying into it but management value system does not lend itself to embracing agile. Caution, you may be wasting your time.

CFC Rating: This project will pose extreme challenges and frustration for you. But it looks like all of your other opportunities right now so go with it!

Any other categories that we should collect? :-)

Published Feb 03 2008, 10:44 PM by Joe Ocampo
Filed under:

Comments

 

Edward J. Stembler said:

You might add some database–related ones such as this:

Staff does not believe in the use of stored procedures and uses dynamic in–code SQL. [I've declined a project because of this once]

Staff does not use primary keys, or indexes, or constraints on database tables.  [I have a friend suffering though a project like this now]

February 3, 2008 11:24 PM
 

bogardj said:

@Edward

Isn't NHibernate dynamically generated SQL?

How about this one: "Client believes typed datasets are the ideal data access layer"

or

"Ex-developer, now manager still holds sway on technical decisions"

February 4, 2008 7:59 AM
 

Edward J. Stembler said:

@bogardj:

Well, what I really meant was SQL statements which are hard–coded in the source code and concatenated with variable values at run–time.

February 4, 2008 10:45 AM
 

bogardj said:

@Edward

Ah, I see! So no understanding of SQL injection attacks, fun fun! :)

February 4, 2008 11:12 AM
 

Donn Felker said:

Well said... I can't count how many times I've been in this situation. :)

February 5, 2008 12:44 AM
 

Joe Ocampo said:

The unfortunate reality is that we are always encountering this.  :-)

February 5, 2008 10:02 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Copyright Los Techies 2007. All rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems