Old School Delphi, Agile is a buzzword?

I was reading a comment in reply to this post on DelphiExtreme, by Ken Knopfli, and I quote:

Delphi programmers tend to be old experienced hands, have seen it all before, and can see hype for what it is.

Most of us have years of experience and have developed our own way of working. A young chap here is a big fan of D/NUnit and now we have two people that do nothing but create and maintain unit tests. Uh huh.

My customers want results and don’t care if I am “behind the times".

I think it's sad and wrong to think like that. We've all used RAD tools for many years, be it Delphi, Visual Basic or Visual Studio. Used like demoware they have one fundamental flaw, they create unmaintainable solutions in more ways than one. Agile practices, among other things, are about trying to prevent that.

Unit testing is not only about testing your code in isolation. It's about regression testing. Creating unit tests allows you to test your code anytime you introduce a change, be it a bug fix, be it a new feature. Unit Testing is about documentation. It's about letting a new member of your team understand the specs of the application one step at a time. Unit test can be and many times is (TDD) about design.

Separation of concerns, single responsibility, loose coupling are not buzzwords. They are fundamental design principles that can save you in the long and short term.

In reference to Lex's comment, I'll be doing talks both at SDC and at EKon (European CodeGear) about these topics, so if you're in Europe and interested, might be worthwhile coming. In any case, these are principles that can be taught irrelevant of the language, be it Delphi, C#, Lisp or Smalltalk. It's about good object orientated programming, it's not about a platform or an environment. Let's stop being the children of the drag'n'drop era.

11 thoughts on “Old School Delphi, Agile is a buzzword?

  1. Adrián Avila

    What some people don’t realease is that maybe it takes more time to construct a solid and reusable base for your applications but are real time saver in the long run.

    The drag and drop era is over, get your hands dirthy and code with objects, you won’t regret it.

    Reply
  2. giulio

    If you do serious software applications and don’t test (for regression or any other reason) your code, you’ll spend more time and money repairing your software than writing code.
    I mantain several millions of code lines (if you like old metrics…) and all problems is connected to bad tested applications or regressions of code.
    Well said, Hadi!

    Reply
  3. jdawkins

    Thanks Hadi.

    Good luck at SDC and EKon. Wish I could be there to catch your sessions. I’m sure they’ll be great!

    Reply
  4. Lars Fosdal

    I think the most important thing about applied software methodologies is that you observe, adapt and improve your processes over time. There usually is not one single methodology or process that solve all your problems, but sensibly applying what you have learned works, and which is suitable for your current problem, which will reduce your work over time.

    Writing test harnessing for your code should be done according to the quality level requirements for the code you produce. If the code is used in critical systems, or is in a constant state of change – the more rigorous testing you need. If the code has low rate of change and is less critical – you may chose to apply the Pareto rule and get 80% testing for 20% effort.

    Using the latest buzzword methodology is less important that actually having a development strategy and sticking to it – while applying common sense and trying to learn and improve as you go along.

    Reply
  5. JB

    Testing is always important and lots of experience (Programming, Diverse Technologies and Business Processes) does reduce testing time but will never eliminate it. In my case, I do not use formal testing tools as they are a waste of time to me, but I do extensive testing before giving it to a Second person that knows how to test properly. In this way our delivery ratio of "large complex integrated business systems" (2 resources) is approximately 50% Development, 10% Testing, and 40% User Training & Implementation. This include re-works to fix bugs and performance issues uncovered during testing.

    I think the key to high production/delivery rates are: Experience, Business Knowledge and Low (or zero) staff turnover of key resources. Using Delphi to Develop Software Tools & Libraries may have diffirent experiences than developing Integrated Business Applications and may well require proportionally more testing time. Also the level of re-use of code may reduce testing time required. I have a lot of re-use of prior developed code that normally requires only a quick test in the context that it is re-used.

    Invariably problems from customers are due to matters that does not relate to the software system, IE. Customer Staff Turnover, Hardware & Network Failures, changes in Business requiring re-configuration or changes of the software etc.

    Reply
  6. Ken Knopfli

    My original, brief comment has been put into a totally different context here. Please allow me to respond:

    1. Extreme Programming, Agile, Unified Modeling Language, Design Patterns, Ed Yourdon’s Structured Analysis, Tom DeMarco, Tim Lister, Page-Jones… all are schools of thought that any programmer can benefit from by reading and being aware of them. But the tools, courses and conferences that grow up around them are expensive in time and money. Having spent all that money, Management now insists you squeeze the customer’s requirements into a set of formalisms and tools, instead of the other way around. At their most damaging, you end up with Tamagotchi-driven Development.

    2. "Separation of concerns, single responsibility, loose coupling are not buzzwords. They are fundamental design principles"… Indeed. They are as old as software development itself. "Agile" is the buzzword. Co-opting these terms under the "Agile" banner does not lend it credibility.

    3. I don’t know why demoware is being put down. I would have killed to get Dan Bricklin’s demo tool back in the Turbo Pascal days. When Borland introduced Delphi, I was able to demo clickable forms and dialogs and ask the customer, "is this what you meant?". We communicated on the same level. Vastly better than piles of abstract specification documents, infinitely better than expecting the customer to understand, say, UML. But to suggest anyone but a newbie is still putting all of the code into the default event handler and therefore must attend an Agile course is disingenuous.

    4. Regression/Unit testing is good. Delphi programmers will create some test forms with one button almost by instinct, and may be all a project needs. But XP assumes it is necessary to drive the development process from this end. If this is really what is needed, the only reason can be that the requirements were not clear from the beginning.

    The dirty secret to software development is getting to understand the customer’s requirements. Thoroughly. Forwards and backwards. You, as a programmer, are nothing more than a glorified Technical Author. You can write in the language of the computer. You know how to use the "word processing" tools. However, an Accountant (who may only write with pen and paper) will write a more useful book on the subject of Accountancy than you will.

    In any software project, you must find the person that actually does the work, establish a good working relationship, and realize you are essentially that person’s ghost writer. This is the person(s) that REALLY understands the business case. Do this and you have circumvented 90% of potential problems; problems that no tool will solve.

    Reply
  7. Jon Lennart Aasenden

    What the.. comparing Delphi to VB is like comparing a Fiat to a tank! VB is not a true development system. You could easily write a bytecompiler in delphi and create a VB clone.

    As far as testing goes, i am more than happy with a log file and compiler switches. Big unit tests tend to become overly.. well, lets just say that you loose focus of the product over the testing. Suddenly you have spend weeks (on a project that takes months) adapting code to your tests, only to discover that the guy that used a text-file and compiler switches is finished already.

    Reply
  8. Hadi Hariri

    @Ken

    First of all, I don’t know why it’s been put out of context. Can you please clarify? In reply to your comments:

    Regarding point 2: agile is about adapting to change. Separation of conerns, loose coupling and single responsabiltiy allow for change.

    Regarding point 3: please see my post "User Interfaces and TDD" from the 14th Sept 2008. Demoware used to create prototype is fine. Delivering protoypes as the product is bad.

    Regarding point 4: You are completely missing the point. Again, see my post from yesterday regarding TDD, if that is what you mean. Plus unit tests do not imply TDD

    We no doubt agree that understanding the customer’s needs is fundamental. But one thing doesn’t imply the other. Or just because you are an exceptional driver you don’t wear a seatbelt?

    @Jon

    Sorry, can you tell me where I was comparing Delphi to VB? In any case, it’s irrelevant. In regard to log file and compiler switches, you mean that you replace testing with production debugging? Creating unit tests for an existing project does involve a tremendous amount of effort, and sometimes (actually many times) it doesn’t pay off to do so. But I’m not talking about existing projects. I’m talking about design principles and applying them to new projects.

    Reply
  9. Ken Knopfli

    It’s out of context because my comment was in reply to jdawkins’ plea: "…learn and implement all the practices of eXtreme programming…it’s hard to understand why we as a community have not embraced them".

    I was explaining that a typical Delphi programmer, having long experience, will probably have suffered under the yoke of several methodology regimes and is unlikely to be enthusiastic about embracing yet another one. Nothing more.

    2. Separation of concerns, single responsibility and loose coupling refer to good programming practice that we aspired to in the days when I was doing embedded processor programming 20 years ago in PL-M. All methodologies promote them under various labels and it amuses me to see them being claimed for Agile.

    3. Of course, but why would anyone deliver a demo? :: The customer has a bad day? He gets carried away the button position and the color of the background? Thinks the demo is the finished product? These are cliches. It is the programmer/analyst’s responsibility to drive the situation and to find a way of communicating with the customer suited to his level of expertise, personality, even temperament. You must reach out to him, not expect him to understand your methodology.

    Your TDD example demonstrates what happens when the tool is relied upon to drive the process. Tools can never be a replacement for common sense, and this applies to all methodologies. But having invested heavily in tools, a team often finds itself riding a tiger.

    4. I posted a comment on your posting of the 14th, add to that my observation above.

    "because you are an exceptional driver you don’t wear a seatbelt?"
    No. It’s because I ride a bicycle. And that is not a frivolous joke.

    If, after preliminary analysis it is clear you are going to be facing constant changes, by all means get that seatbelt. If not, it will just drag the process down. A helmet and elbow pads may be better.

    I am looking across at my bookshelf: Design Patterns, Pattern Hatching, Pattern Languages of Program Design, Object-Oriented Design Heuristics, Pitfalls of Object-Oriented Development, Writing Solid Code, Debugging the Development Process, The Unified Modeling Language User Guide, The Rational Unified Process and Introduction, Visual Modeling with Rational Rose and UML; and Steve McConnell’s two most excellent but C-Oriented tomes: Code Complete and Rapid Development books. At home I have the aforementioned Yourdon, DeMarco and Lister books, plus the classic Fred Brooks "Man Month" book.

    I have read them all.

    When I joined this company, everyone had been to Rational Rose courses and had expensive Rational toolsets installed on their PCs. There are course notes and training guides on everybody’s desk. Nobody actually seems uses them.

    Why?

    With very few exceptions, you come to realize that each design book or methodology grows out of the experience of one or a group of developers. No surprise there. But this experience is specific to the types of problems the group faced, the field in which they worked, the kind of development tools available to them; sometimes even specific to the problems arising from the programming language used (McConnell).

    Further, each methodology evolves to the point where it becomes self-serving; tools get created and the whole thing becomes a Tamagotchi, an electronic creature needing constant attention.

    I am not against any of these methodologies. I urge programmers to read up on them. Learn from the experience of others and use what is appropriate in your situation. But keep a keen sense for the point at which the tail begins to wag the dog.

    Right: I’ve said enough now.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s