Home > Coaching, Development, discourse, Education, People, programming, technical > Agile Software Developer Terminology for New Programmers

Agile Software Developer Terminology for New Programmers

December 21st, 2012

This is a post for new developers, young, inexperienced or old and retraining into information technology.

Recently, I had a discussion with many engineers at one of those many London user group nights about how there is so much new stuff that we have to explain to people new to programming. One person had to coach a graduate developer on writing unit tests. Another person had to explain the reasons why dependency injection is better than dependency lookup.  I can recall similarly stuff, being able to gently and concise explain why we should have unit tests in the code, and why we need them.

Here is my current matrix of terms:

Term Description
YAGNI You Are Not Going To Need It – The issue hare is that far more code is written than necessary to solve or deliver application functionality. 

Classic symptom: Added unused finder methods to session beans in Java EE

DRY Don’t Repeat Yourself – writing code that has lot of duplication across methods, classes, packages and package object. 

Classic symptoms: Copy & Paste coding in unit tests and repeated metadata in entity and the front end

KISS Keep It Simple Silly [or Stupid] – a mantra to describe writing only code to solve the function problem instead of writing a less complicated codeAlso see Occam’s Razor.

 

Classic symptom: Too many abstract layers in a software application

WET Write Every Time – the antithesis to DRY, where code is deliberately written that repeats lots and lots of time in different classes, packages, and functions. 

Symptoms: Deciding to do things your way and instead of collaborating with the other developers and finding some common ground.Classic antidote: DRY, Unit Tests and Code Refactoring.

WETTT Write Everything Ten Thousand Times – the hyperbole colloquial version of WET
R3 Rules of Three – This is not the proprietary operating system of the same name, or the classic 1980′s arcade game, or either the description of a maxed out pimp-my-ride Volkswagen Golf; but the idea that when ever you have three duplicated parts of code in a method, function or classes then it is time to refactor the duplication in to single method. See Rule of Three computer programming. 

Related to DRY and WET

 

Class Symptom: Ignoring the code repeats because of time pressures, or the Scrum master says no, don’t do it in this sprint.

DBC Design By Contract – the idea of building a service from a contract first. In Java you write the interface as simply as possible and then secondly worry about the implementation class.

 

Interfaces are easier to refactor around and because you can plug different implementations into the interface you get higher cohesion and lower coupling.

 

Classic Example: JDBC specification since version 1.0. There are tons of implementations for different relational databases including MySQL, Postgres, H2, Derby etc.  Every Java programmer knows how to code against JDBC because that they don’t have to fight with an different implementation, which vary, because the DBC implied it will do the right thing most of the time.

 

Also related to standardisation of application programming interfaces.

BDUF or BUDF Big Up-Front Design – a problem with many large corporate institutions that sometimes require a 100 – 1000 page document full of business requirement before any software construction gets the green lightSome poor architect or business analyst will have spent weeks investigating and chatting to the business about the requirement, only for the development team to say the document is practically worthless.

 

Antidote: Get the technical lead and some key developers talking with the business and the analysts and the customer. Ideation sessions everybody!Symptom: Waterfall methodology and aspects of the investment banking IT culture

 

Antidote: Unknown, lots of people how tried to bring “Agile” with both a big A and small A to many of these institutions with some success and failure

Pink Book Describes the book with a Pink Cover called Extreme Programming Installed by Ron Jeffries, Ann Andersen, and Chet Hendrickson. I do not recommend this for new starters unless for reference, since the Pink Book is now rather old, 2000, there are other more recent Agile development books and courses that help new Java developers.
YOLO You Only Load It Once [If Ever] – this is related to fact that you want to have a single source of truth in an application system. This is problem of mis-architecture, where someone has not thought the functional requirement through enough.

 

Classic Example: Shopping Cart Service EJB – you only ever want one implementation of the pay-point in an application, albeit you will have many pay-point providers (credit and debit card third parties and PayPal)

 

The If-Ever part is YOLO and YAGNI added together. You are not sure of the another part of the system loads the data, so you decide to keep the component. (You probably want to put a logging client on the YOLOIF thing so that you can effectively decide to chuck the component if nobody has used the function in 12 or 18 months time.)

 

Digression: If you have find data that is constantly being uploaded to serve a web request then perhaps it really needs caching and not YOLO.

Spike A quick exploration of coding in Sprint in SCRUM methodology, which is also time-boxed inside a single sprint, usually. In a Spike you are probably are looking an new API, like a cloud service or user interface API like JavaFX or similar and basically you explore if the function can implemented relatively well in the new API.In short, you are trying to build some confidence in a new area before committing yourself and other resources to it. Spikes are usually contained and protected from the flow of the critical path and restricted to a time length. See SMART goals. Once your team has gained confidence and knowledge in the new “thing” then reasonable estimates can be made.

 

Classic Examples: Adopting a build system – moving from Apache Ant to Maven; moving from Subversion to Git; Adopting a new open source library

TDD Test Driven Development – often conflicted as not being fully explained as a change of discipline and mind.”You are only ever doing one of these four things: writing unit tests, writing production code, refactoring unit tests, and refactoring production code; and never doing more than one at these previous at the same time.”
TFD Test First Development – builds on the ideas of TDD and then extends the discipline to writing unit test code before any production code.”Once you have a brand new unit test written completely, then you make sure that new unit test(s) actually fail in order to switch over to writing production code ensures the the new test passes.  After you have done that, you refactor the tests. Run all tests for all the green bars. Refactor the production code and runs the tests for all the green bar.Repeat: Go back to the start; write a new unit to that will check validate operation of the next function for the application. Repeat with the same formula as above.”

 

Velocity This is often misunderstood as a very basic measurement on the Return-on-Investment for SCRUM/XP software development and it has nothing at all to do with financial services, budgets and/or reporting. The creators of SCRUM/XP now disuade velocity as a ROI indicator at all.

 

Velocity is the number of story points completed per team per iteration. To the SCRUM/XP  experienced: Velocity is equal to the aggregated units of work completed over aggregated time intervals, which implies you measure each progress of tasks in two or more sprints.

Story Point For each user story in the sprint or task, predict  how hard it is to implement by using unit of reference. 

Story points are usually written in Fibonacci numbers: 0, 1, 1, 3, 5, 8, 13, 21, 34, 55, 89, 144Every agile team in the world has a definition of a user story unit point.Teams decide on the backlog items in order to come up with predictions and these joint predictions every member of team go to decide what should applied to the next sprint.

DTSTTCPW Do The Simplest Thing That Could Possibly Work – Related to Spike and KISS in many ways. If you are pressed for time and some trading systems developers in investment bank are then this is your working life. 

DTSTTCPW certainly invites team collaboration and effective sound-boarding from other developers and members of the team, otherwise you are asking for trouble.

VoC Voice of the Customer – This is a term from SCRUM methodology, but I am about 20% unsure about this one; I believe 80% of the time to mean a proxy, a placeholder, for the real customer, the person who understands the business requirement and will of the customer. Because the true user is unavailable for some reason due to authority, culture or organisation, or even geo-location. 

Some people have amusing called this abbreviation, the Voice of Reason, especially when they do not enjoy working with the customer directly.

Unit Test In Java programming, a Unit Test is a Java JUnit framework test class or TestNG framework test class that specifically verified and validates a single function of work in an application 

A unit test requires a target, which can be a Java Class, a Service Bean, Managed Bean or something implements the said functionality.

 

Unit test are often seen as low-level fast and efficient tests.

Functional Test A functional test is a larger test, which can also be a unit test, designed to test packages of classes or sub part of the overall application infrastructure. Functional test validates if the application meets one of the customer’s external requirements on performance, results and efficiency.

 

Symptom: a functional test is not necessarily a unit test, and not all functional tests are acceptance tests.

Acceptance Test An acceptance test is the same as a functional test in name only. Acceptance tests are those where the customer wants to see the validation pass in order they sign of the implementation. 

Symptom: If the customer is disastisfied with the application at demonstration time, then at least the one of the acceptance test is broken. Add one in the next sprint.

SOLID A set of five principles:Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation and Dependency Inversion.
Single Responsibility Principle An object class, a service bean, web service, a function or procedure should have only one single responsibilitySymptom: It is hard to write unit test for complex object, because it doing WETTT
Open Closed Principle Open for extension and closed for modificationIt means you can subclass the object, but the object is encapsulated by not allowing an outside object to gainfully change the internals. 

Symptom: leakage in object implementation, hard code dependency, and not working with Java interfaces (or interface like constructs i.e. Scala traits and mix-ins)

Liskov Substitution Principle Idea of swap-ability and is expressed as a Design By Contract (DBC).I can swap in another object X which is an implementation of T if that objects is a type of T and the overall application works.This is the basis of mocking objects, mocking implementation frameworks; testing in general; proxy remote objects, persistence capable objects; application server and lifecycle monitoring situations; plug-and-play and restartable applications. I could go on, but I won’t.
Interface Segregation Principle A service interface that does only single specific functional thing is better than a service interface that does several different things. 

Symptom: Failure to adhere to the KISS principle. In days gone, the non standard C++ String libraries where everybody threw in the kitchen sink of methods for any operation that one would want to write that manipulated a C/C++ String (char*)

Dependency Inversion Principle Idea of not hard-wiring a direct relationship to a dependent into object.In Java EE world, you would use a dependency injection container such as CDI to inject different managed beans into a service bean. 

Dependency inversion also should mean in my humble opinion given up on managing the life-cycle of service components and beans. The lifecycle is managed by the application container, the cloud provider or whatever it is you are using.

 

In another school of thought: every application is managed these days, whether it is the operating system, a virtual machine or web container or mobile platform (iOS and Android). This is the way forward.

Design Patterns A classic book on Design Patterns by Erich Gamma et Al. 

Ask your local technical leader to lend you his or her copy of the book; and if they don’t have a copy then that really sucks. Tell them to give you a personal training budget and buy the book yourself!

Glad to be of service to all my readers.

Merry Xmas and Happy New Year 2013!

+PP+

PS: I, once, had a notebook and file with a lot more of these terms with or without explanations. If I find anymore abbreviations and terms that I will add to this blog entry.

  • http://profiles.google.com/daverooneyca Dave Rooney

    Peter,

    Generally, a good list. Some comments:

    1) Uh, who is “Ron Hendries”? I believe you mean Ron Jeffries, Chet Hendrickson and Ann Anderson.

    2) Scrum is not an acronym and thus shouldn’t be written all in capitals

    3) Spike and Velocity originated with XP, not Scrum

    4) A spike is a time-boxed investigation of something when you don’t have enough information to be able to provide a reasonable estimate for some work.

    5) “[velocity is] A very basic measurement on the Return-on-Investment”. No it isn’t, and that’s why so many agile practitioners (including those who created the terms story points and velocity) are now advising that you don’t use it. The following sentence is correct, though.

    6) Your description of TFD is how TDD was originally described and how I learned it in 2000.

  • http://xenonique.co.uk/ admin

    Dave

    Thanks for your response. Thanks for spotting the error with Ron Jeffries name. I have given them full credit.
    I still think that TDD is misunderstood, because even though it should have been written TFD, some organisations and teams do not and will never practice test first. There was life before TFD and for many creative and scientific styles of programming, it does not make sense. For example you can TFD on a Disney/Pixar animation, this is a programming visual media and not really an assertion. Another example, TFD when writing an new algorithm for Quant trading, your Monte Carlo methods are leading to approximations for wider analysis, I think it is difficult to TFD for those types of applications. Certainly, TFD does help in product engineering.