Click here to monitor SSC

Simple-Talk columnist

On the trail with the Cowboy Coders.

Published 24 October 2007 5:43 am

One of the signs of increasing age in the IT industry is that of ‘déjà vu’. New things that are laboriously explained to you ring all sorts of bells. The past flashes before one’s eyes.

I visited a company developing Internet-based applications the other day. They were proud of their progressiveness and explained to me that they developed database systems using the radical new Agile XP (Extreme Programming) methodology. Wow, I thought. That must have impressed the shareholders. Perhaps they don’t realize that Agile XP is known in the industry as ‘Cowboy Coding’.

I feigned ignorance, which is not usually hard for me to do.

‘Well,’ said my genial and pleasant host, ‘one of the great things about Agile XP is that one tests every part of your code as soon as you’ve written it and you don’t go on to the next bit until it has been thoroughly tested. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break.’

‘Gosh! You mean you test your code rather than just write it?’.

‘Ingenious isn’t it. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production.’

‘Funny how nobody has ever thought of this before.’ My face goes red when I’m desperately trying to stop myself guffawing with laughter. What I love best about working in IT is its rich unintended comedy. My host misunderstood my visceral difficulties as excitement

‘Because you can never be certain that what you coded is what you meant XP uses what it calls ‘Unit Tests’. These are automated tests that test the code. The programmer will try to write as many tests he or she can think of that might break the code he or she is writing; if all tests run successfully then the coding is complete, and the programmer can then go on to develop more code.’

My eyes bulged. My face flushed red.

Seeing how interested I was he proudly produced an elaborate Java-based module he’d written that provided a test harness for SQL queries and procedure. ‘It is great, you can change the parameters in the query (Klop Klop Klop on the keyboard) just type in what results you expect’, (Klop Klop Klop Klop), ‘and then Run the test harness’ (Klop Klop Klop Klop Klop Klop)

Various windows flashed on the screen in front of me, full of inscrutable commands. It was all very ‘Seventies’.

Finally a message popped up from the depths saying ‘OK’. He was so proud; it could have been his baby.

‘Look, all we have to do is to change SQL code a bit in order to simulate an error and you’ll see what happens!’

(Klop Klop Klop Klop Klop Klop)

Wow. An error message popped up saying there was an error in the code.

‘To think that, for all these years, we’ve been doing it so stupidly’ I sighed, shaking my head in mock-regret. I’m afraid I wasn’t able to show him the way that a SQL Programmer like myself would go around doing the same thing in their humble rudimentary way. I hope I explained enough to suggest that that perhaps there has been some sort of primitive thought before the genesis of Agile XP.

Before you write code, you write a test-harness. (it is often best to get someone else to do it, preferably someone with malice in their soul). When you write the piece of SQL code, such as a function, you append the test harness for unit-testing purposes. In some places I’ve worked, you’d be given a rough time at code-review if these were missing or inadequate. Here is an example…. (normally, you comment out the test harness when the code is ‘put to bed’ and the GO moved to the end, so that the harness stays with the code, or you can, in SQL Server, save it as an extended property.)


– =============================================
– Author: Phil Factor
– Create date:
– Description: Reverse Charindex. Gives the index
– INTO the string OF the LAST occurence OF the
– substring
– =============================================
ALTER FUNCTION [dbo].[rCharindex] –reverse Charindex
(
  
– Add the parameters for the function here
  
@needle VARCHAR(80),    –the substring
  
@HayStack VARCHAR(8000) –the string
)
RETURNS INT
AS
BEGIN
   IF
@needle+@Haystack IS NULL RETURN NULL
  
IF CHARINDEX(@needle,@haystack)=0 RETURN 0
  
RETURN COALESCE(LEN(REPLACE(@haystack,‘ ‘,‘|’))
             -
CHARINDEX(REVERSE(@needle),
                      
REVERSE(@needle+@haystack)
                       )
              -
LEN(REPLACE(@needle,‘ ‘,‘|’))+2,0)

END
GO
DECLARE @Test VARCHAR(80)
SET @Test=‘First test’—————————-
IF dbo.rcharindex (‘this’,‘This can NOT be a thistle ‘)
   <>
19
  
RAISERROR (‘Failed the %s’,16,1,@test)
SET @Test=‘Second test’—————————
IF dbo.rcharindex (‘pr’,
  
‘  May the lord preserve me from the priests of the IT industry  ’)
   <>
37
  
RAISERROR (‘Failed the %s’,16,1,@test)
SET @Test=‘Third test’—————————
IF dbo.rcharindex (‘l’,
  
‘…who maintain an evangelical following.. ‘)
   <>
35
  
RAISERROR (‘Failed the %s’,16,1,@test)
SET @Test=‘Fourth test’—————————
IF dbo.rcharindex (NULL,
  
‘…by waving their hands a lot.. ‘)
  
IS NOT NULL
  
RAISERROR (‘Failed the %s’,16,1,@test)
SET @Test=‘Fifth test’—————————
IF dbo.rcharindex (‘ without their ties on.’,NULL)
  
IS NOT NULL
  
RAISERROR (‘Failed the %s’,16,1,@test)
SET @Test=‘Sixth test’—————————
IF dbo.rcharindex (,)
   <>
0
  
RAISERROR (‘Failed the %s’,16,1,@test)  
SET @Test=‘Seventh test’—————————
IF dbo.rcharindex (,‘and looking sincere’)
   <>
0
  
RAISERROR (‘Failed the %s’,16,1,@test)  
SET @Test=‘Eighth test’—————————
IF dbo.rcharindex (‘but it adds to life”s rich humour’,)
   <>
0
SET @Test=‘Ninth test’—————————
IF dbo.rcharindex (‘Klop’,‘so perhaps one should be tolerant’)
   <>
0
  
RAISERROR (‘Failed the %s’,16,1,@test)  
SET @Test=‘Tenth test’—————————
IF dbo.rcharindex (‘Klop’,‘KlopKlopKlop ‘)
   <>
9
  
RAISERROR (‘Failed the %s’,16,1,@test)  
SET @Test=‘Eleventh test’—————————
IF dbo.rcharindex (‘ Klop ‘,‘Klop Klop Klop ‘)
   <>
10
  
RAISERROR (‘Failed the %s’,16,1,@test)  
SET @Test=‘Twelveth test’—————————
IF dbo.rcharindex (‘ ‘,‘      ’)
   <>
6
  
RAISERROR (‘Failed the %s’,16,1,@test)  

SET @Test=‘Thirteenth test’—————————
IF dbo.rcharindex (‘ ! ‘,‘ ! !!!  !  !!!     ‘)
   <>
8
  
RAISERROR (‘Failed the %s’,16,1,@test)  

There are many cleverer ways of doing it but I blush to think of the stupid bugs that this sort of system catches, that slip through casual testing.

7 Responses to “On the trail with the Cowboy Coders.”

  1. Anonymous says:

    Amen brother.

    “Perhaps they don’t realize that Agile XP is known in the industry as ‘Cowboy Coding’. ”

    Classic.

  2. warlock_za says:

    I have to disagree with your disdain with Agile XP Phil old boy. Many of us exhibit paranoia, and naturally code ‘defensively’, ie lots of testing, self checking, and validation. That is not to say, old Chum, that every programmer does…

    What Agile XP is trying to accomplish with unit testing , is to basically instill as part of the development process, the natural defensive coding instinct that a lot of us perform naturally (Instinctively?)…

    A lot of the Agile stuff is plain common sense and it could be said that some of us have been developing all along in an Agile XP manner, even though it wasn’t called that. Its nice that there is now a process that forces developers to code defensively.

    Can you imagine the difference if Windows was actually checked for bugs before it was shipped? …

    Yeeehawww…..

  3. Phil Factor says:

    Parts of Agile XP are wonderful, but these parts don’t necessarily make a whole.

    Defensive coding is part of the discipline of team-working, and always has been. Agile XP, to this extent, is simply ‘mutton dressed as lamb’. Something that we already recognise as good standard programming practice can hardly be then adopted as the cornerstone of a radical new methodology, and Agile XP is hardly the first methodology that forced programmers to code defensively.- it is an intrinsic part of the methodologies that Agile XP evengelists like to denigrate

    The reason that the term ‘Cowboy Coding’ tickled me is that experience tells me that time spent getting requirements right, getting the design right, and understanding the data, is time better spent than in iterating prototypes and ‘evolving’ applications. ‘The advocates of XP argue that the only truly important product of the system development process is code’. (from Wikipedia) Agile spurns documentation. My belief and experience is that, if a Development Team cannot clearly document the design and specification of an Application before they code it, they are doomed to fail. Sure you might need to change the design, but it’s got to be there. You can build an application iteratively as easily as you can build an aircraft or a ship iteratively

  4. GSquared says:

    Agile has some good things, but they are generally the parts of it that every practice includes. Unit testing, not writing more code till what you’ve already written works as expected, teamwork, yes. Disdain for documentation, requirements, and planning, are not good things.

    I’ve seen a lot of software that contains far too much spaghetti code to handle things that “came up while evolving the software”, that could have been done right the first time if someone had taken a little time to plan and blueprint the code from well-state requirements.

    Sure, getting right to the coding works if you’re doing a small project for a short-term program, with only a few users. For example, a simple Word macro.

    But if you save a few days up front by avoiding requirement documentation, and a few more days by avoiding a solid plan, and another day during the process by avoiding documentation (and, from what I can tell, these are the main goals of Agile XP), in a major project, what you end up doing is adding weeks of work later when nobody knows what a module is supposed to, why it’s supposed to do it, or how it’s supposed to fit in. Or years of re-working things because nobody thought that the accounting program might need to generate audit trails for the last 7 years, because none of the developers happen to know that the IRS expects such audit data, and nobody put it in the non-existant spec.

    One of the leading proponents of Agile wrote a book on “The Agile DBA”, on how to refactor databases. (It’s available on Amazon.) I read it, hoping to learn something useful. Turns out, the title could almost have been, “A Collection of Worst Practices: Or How I Stopped Worrying and Learned to Love Poor Database Performance and Lost Data”. It actually recommends keeping data in more than one table by adding duplicate columns to multiple tables, and keeping them synchronized through complex triggers, in order to make it easier on the front-end developers when they need to access the data; and this is done in order to avoid having to access data through stored procedures (after all, having lots of triggers is better than using a proc or two, right?).

    Agile is all about saving a little time now in order to waste a lot more time later, in my experience.

    Nothing wrong with software that evolves over time. Actually, it is necessary. But there’s a LOT wrong with avoiding a little planning and preparation when it (inevitably) results in a higher cost than the gain from it.

    I love asking Agile XP proponents if they’d like to visit a doctor who started surgery on them, without diagnosing the problem first, and without planning out where EXACTLY to cut, what to do, etc., and then refused to document what was done in a medical record. It’s what they are asking programmers to do. After all, “once we’ve cut you open, we can begin unit testing your organs and the changes we make to them, till the whole thing starts working better”.

  5. Anonymous says:

    I’m bothered by the fact that you’re bashing TDD in this post, when based on your comments it seems that your real problem is with coding without proper specifications. I agree that some of the agile people go way too far in that direction, which can only result in lots of wasted time. But I believe that TDD and comprehensive unit test coverage are good things–they cause better software to be produced. Of course, producing software with no specification does not result in quality, so we need to take some parts of the methodology and ditch others…

  6. Phil Factor says:

    It was never my intention to bash the practice of thorough unit testing and regression testing. On the contrary, I thought I was arguing in favour of it. I usually do! TDD and Agile XP trumpet such practices as if they were new exciting developments whereas I remember being taught the concepts in (blush blush) the late 1960s.

  7. Anonymous says:

    We have always used the analogy that software development is like constructing a building. A lot of time goes into the planning and the foundations, the walls and roof go up quickly then a lot of time is spent on finishing and fine detail.

    Never investigated Agile but the boss (who isn’t a time served developer) has gone to London on a course and the 2+2 I’m putting together says it’s on Agile development :-(

Leave a Reply