Scott Mattocks has wrapped up his series about LUCID development with the final letter of the acronym - D is for Documentation.

Despite mankind’s best efforts, writing code is still clearly an exercise for talking to computers. It has not evolved to the point where talking to a computer is as easy and natural as talking to other people. That’s why documentation is so important. Programming languages are just a translation of a developer’s intent into something a computer can execute.

He points out that even a little documentation can go a long way (even in presentations with code in the slides). It provides context and the intent of the code, not just details about what it's doing. He proposes a compliment practice to test-driven development (TDD) that turns the documentation process around - Documentation Driven Development. This is essentially writing up what the code does first, then writing tests to check it and only then writing the code to make it happen.

If you're interested in the rest of the articles in the series, check out the LUCID article on his site with links to each letter's article.

Scott Mattocks has posted the next "letter" in his LUCID development series (more here) - the I is for Isolation:

Applications are a collection of individual components; they pull together the contributions of individuals to create something which is greater than the sum of its parts. If one piece breaks down, and the system is not prepared to put it in quarantine, the entire application can come crashing down. [...] The best way to stave off this infection is to prevent it at the source. Keep the application happy by making it more resistant to implosion.

He talks about the "code jerks" of your application that hog resources or functionality and cause general problems for the application as a whole. He notes that sometimes it's the result of a third party, but it can also be internal (and more difficult to find). He gives a more specific example of a database wrapper class and some suggestions of things to do as failover (ex. used cached data or read from a secondary).

Scott Mattocks has posted the next in his "LUCID development" series of posts with the next letter in the acronym, "C" for Configurable:

As code moves through the software development process, it moves through different environments. In many cases, the full details of then environment may not even be known at the time development starts. Getting your code to change its behavior on the fly is only possible if you have carefully and thoughtfully interleaved configuration parameters into your code.

He talks about handling configuration for external systems and the responsibility that comes with access to the connection information for resources. He makes some recommendations as to where to start if you're looking for places in your code to change how configuration options are used - low hanging fruit like code that accesses external systems.

Other parts of this LUCID series so far are: L (Logging) and U (Unit tests).

Returning with another part of his series on his concept of LUCID development, Scott Mattocks has this new post for the "U" about unit testing.

Unit tests are like Google Maps for your code. When you zoom in and look at small pieces, you can only go so far. However, when you zoom out and take a look from a greater distance, you can see the full path from A to B. The idea of unit testing, as it relates to LUCID development, is that it maps out all the different ways to get from one end of your application to the other. Unit tests take the question of “how does my data get from the my user’s request, through my code and back to the user again?” They answer that question just like any well written application: by breaking it down into smaller more manageable chunks.

He talks some about the purpose of the tests themselves - finding the exact point where something goes wrong, answering one question at a time. He points out that testing isn't just something that's to be done when the code is first written. The tests need to be continuously groomed and updated as things change too.

You can find the first part of the series, "L is for Logging" here.

Scott Mattocks has started off his series about the LUCID development methodology (one he recently proposed) with the first article covering "L" for Logging.

Communication is the only way you can tell if an application is feeling well or is about to fall apart. If your application can’t talk to you, you have no way of helping it to feel better. The L in LUCID is for logging. Logs are how applications speak. They capture information that allows us to pick up on those little signs and act early enough to make sure the application doesn’t come down with the flu. If you don’t have good logging throughout your system, the best you can do is react to your application falling over. A silent application is an application destined to cause midnight surprises for you and your operations team.

He talks about the difference between "just logging" and "correct logging" as well as a recommendation for the different levels: trace, debug, info, warn and error.

Letting you know that something went wrong is really only half of a log messages job. The other responsibilities of a log message are to allow you to accurately reproduce the conditions under which the event occurred, and to allow you to fix any data inconsistencies.

Scott Mattocks has a new post to his site today about a set of development principles he's proposing called "LUCID" (similar in idea to SOLID) - Logs, Unit Tested, Configurable, has Isolated features and is fully Documented.

Building software with a clear set of use cases and requirements is a relatively straight forward process. Various design patterns exist to help you solve problems which others have come across already. You can use principles like SOLID to help separate your classes and simplify your code. [...] Using a set of guidelines like SOLID may make it easier to swap out a broken class for a new class, but they don’t really help you identify the problem or fix any data corruption which may have occurred. Knowing you have a problem and being able to isolate and fix the problem is just as important, if not more so, than being able to rely on consistent interfaces from your factory method. That is why I am proposing an additional set of software development guidelines called “LUCID code.”

He defines it as "code with understands that bugs are unavoidable" and is able to give developers feedback through its own logging, tests and documentation. With correctly isolated code, development can be segmented and worked at the same time and make changing requirements and updating functionality simpler in the long run.