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.

These problems are related to the inability to share behavioral code through aggregation and the complexity of state transformations. Combining both, your average entity with 5-15 fields can end up with hundrets or thousands lines of code. The solutions to both problems boil down to minimizing duplication and maximizing clarity.

He looks at two different kinds of objects Doctrine uses in its setup, the value objects and method objects, and "maximize clarity" on them by dividing them up into more functional-related objects, passed into each other via method injection.

Writing code, which is easy to change is the Holy Grail of programming. Welcome to programming nirvana! But things are much more difficult in reality: source code is difficult to understand, dependencies point in countless directions, coupling is annoying, and you soon feel the heat of programming hell. In this tutorial, we will discuss a few principles, techniques and ideas that will help you write code that is easy to change.

He covers some of the good OOP principles to think about when developing - like cohesion, orthogonality and coupling (via class methods, polymorphism, dependency injection or interfaces). He spends some time looking at the SOLID development principles and how you can implement each of them in some sample code. He also talks some about high level design and how the separation of concerns can help make your code easier to maintain and change.

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).

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).

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.

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.

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.

he fundamental things will always apply. If you have an understanding of the underlying ideas of software development, you will quickly adjust to new techniques. In this tutorial, we will discuss three basic principles and mix them with many more. They provide a powerful way of managing the complexity of software. I'll share some of my personal opinions and thoughts, which, hopefully, will prove useful when it comes to applying them to code and real-world projects.

Their three ideas that should always be in mind during development are:

• DRY - Don't Repeat Yourself
• KISS - Keep It Simple Stupid
• "You Ain't Gonna Need It" (YAGNI?)

For each principle, there's a but of an example showing either some current project that follows the idea or a process that can be used to implement it.

Software that requires an enormous amount of changes to implement one new feature or fix a bug is unstable and should be considered as "bad". Software should be designed so, that in case of a new feature, no existing classes should have to change. In other words: it is closed for modification. Existing software may be extended to achieve new features however.

He starts off with a "What" section explaining a bit more about what this open/closed means for your code and gets into an example showing it in a more practical way. He shows how to take the principle and refactor an API connector class to pass in the object it needs (Bike) and use that to get information (rather than just passing in the data). He uses a Factory to get the object type he needs based on the Bike type.