Random Thoughts on Software

Many people create APIs that extends concrete (non-abstract) classes. I have come to avoid this practice. Through the use of design patterns (especially strategy) I have come up with much better designs. It is my preference that classes are either final or abstract. If they are final, nobody can extend them. If they are abstract, then all of their methods should be either final or abstract.

Why shouldn’t you extend a concrete class and override one of its methods? It breaks encapsulation. You have to know about the innards of the class that you are extending. Just because you have an IS-A relationship to another class doesn’t mean that you shouldn’t worry about encapsulation.

http://fishbowl.pastiche.org/2002/12/17/inheritance_taxonomy
http://www.manageability.org/blog/stuff/inheritance_revisited/view
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
http://research.microsoft.com/comapps/docs/Inherit.doc

When developing a new system that is not in production, database design can easily be incremental without much thought. In production systems, however, changes to the database are not as pleasant.

If the database is an interface point between multiple systems, it seems like its worth spending the time to sit down with all involved parties and hammer out the database schema in an upfront fashion. Of course, this doesn’t eternally prevent changes to the database, but it can help standardize an interface. Another approach to standardization of a database-based interface is to use a view, a separate table, or a separate database. Then any database changes that are made to the system must be updated in the mapping that creates the interface (e.g. the view must be updated).

Here are the main types of changes that I have come across and how I’ve handled them:

Changes to the application, no changes to the database

Code changes

Data Changes

Schema Changes

Field name changes

Added fields

Removed fields

Datatype changes

Fields moved to other tables (usually when normalizing)

It’s schema changes that make it difficult when in production. Here are the steps that you have to take when you make changes to the schema:

I always think about ID values as some buried part of the application whose value nobody should ever know or care about. The system I’m working on now is interesting because the employee IDs actually have meaning. The first few digits represent the state, the next few digits essentially represent an area, and the rest is unique to the employee.

I would normally think that this is unnecessary, that they could have just auto-generated a number and assigned it to an employee. But, out in the field, managers and support team members are able to help troubleshoot problems more quickly because of this. Somebody might call up their manager while they’re at the grocery store and ask why one of the employees can’t log into a particular system. After finding out the employee’s id number, the manager can quickly determine what state and region they are from, and where they should have access to.

This type of information-bearing ID can be very useful for quicker troubleshooting. But the ID value with business meaning doesn’t necessarily have to be the primary key on a database table. Hibernate.org recommends using ’synthetic’ (generated, with no business meaning) ID [meaning primary key] values. Could could still have a unique value in your database table that represented the user and still contained some sort of business value.

Decoupling technical and business decisions is very important. Every time I sit in a meeting where technical people are making business decisions and business people are making technical decisions, I get frustrated. This is one aspect of XP that I truly believe in.

No discussion has really taken place regarding the “business requirements” for the project I’m working on. If it has, it was well buried in technical discussion about the database schema. These technical discussions are carried out with the customer. The developers sit down and try to sell the customer on different concepts of database normalization and auto-generation of IDs.

The necessary element is trust, I guess. This customer is so used to approving technical decisions that it might be hard for him to be placed in an environment where he just gives a high-level set user stories (perhaps elaborating on some special cases) and then trusting that the development team will deliver something that will perform the tasks that he wants.

A set of screen mock-up might have been a nice thing to have. That would have given him an idea of the flow of the application from a higher level than the database schema.

I find a lot of parallels between this article on ‘The Role of Simplicity in Writing’ and the role of simplicity in software.

A developer’s source code will inevitibly be read by someone else. That’s why people realize the importance of code reviews. If your source code is complex, then people can’t read it, so they are more likely to want to rewrite it than maintain it.

When I’ve worked in XP environments, it was nice because through pair-programming, collaborative code ownership, refactoring, and TDD, we created code that was simple and that the entire team could understand. We couldn’t really tell who wrote what code in the end. It all looked the same and it was mostly simple.

I often ponder about types of environments where agile methodologies wouldn’t work.

The company I’m working for right now uses no methodology at all. The developers deliver to different groups within the company, mostly creating small Web applications, but also a few that are a bit bigger. Yesterday, I found out about the “process” for adding new features on one of the bigger projects. The developers create whatever they think the customer might want. The customers have absolutely no contact with the developers, because they are separated by 2-3 levels of management and live elsewhere in the country. And, apparently, the customer is pretty happy with what they are getting.

I don’t know how the project got started, but for the most part the developers just guess at what features would be useful and cool, and they provide them. Every once in a while, a VP of something or other will send down a vague suggestion or opinion about the application (which is widely used) and the developers will add whatever they think he meant by it.

The customer and the developers seem happy. Nobody really knows who the “customer” (in an XP sense) really is, but there seem to be no complaints from the userbase or the people whose budget the project comes out of. The “customer” would probably be opposed to having to commit their own time or additional resources to have to come up with user stories or to write customer tests.

Because everybody seems happy, they probably wouldn’t even welcome changes that would “improve” their process. They probably wouldn’t think anything needs to be improved.

What’s wrong with this picture?

I fall into an interesting category of software developers. Most of my experience as a professional software developer (thus far) has been working with agile teams using agile processes.

Most developers who follow agile methods seem to come from the “been there, done that” camp. They have experienced all the non-agile strategies and people. They learned through years of experience why agile was important. I, on the other hand, only worked for a couple of years doing business software before adopting eXtreme Programming around the 1999-2000 timeframe. Ever since that time, I have worked for places that more-or-less accepted agile practices as law.

So, it’s a real eye-opener for me to work with people who just downright don’t know, care, or accept the concepts of TDD, collaborative code ownership, pair programming, project rooms, not checking in broken code, following a process, etc. I see many of their pains, but I can’t just downright tell them that they are doing everything wrong (even though they are).

Convincing people of agile is a delicate process. You have to approach it in the same manner as a strong salesman: by listening for their pain. Offer a business or technical solution to their biggest problems. You just have to make sure that you are really listening to make sure that you really understand the core of their problem. The solution is usually a fundamental practice. You start becoming nag if you are making suggestions for improving things that they don’t really feel like they’re suffering in (even if they are).

I just started working on a new contract as a Web application developer. After working on several “Agile” software projects, I am back on a very non-Agile project.

It is interesting how important concepts in software development get interpreted and implemented by different people. For example, I was told that I should avoid running the unit-tests for the Web applications because they were not designed to be maintained after the feature was done being written. WOW! What a horrible approach to testing. It’s like they read the book on unit-testing, but they skipped over the chapter that explained the concepts behind having regression capbilities.

I had to explain the benefit of maintaining library dependencies in the repository. They were maintaining third-party libraries on a shared network drive. The main argument was that they didn’t want the repository to get too big, where too big was several hundred megs. After making a convincing argument about hard-drives being cheap and the many problems that can occur when you don’t version control your libraries with your source, they agreed to let me fix the problem.

The developers tend to approach everything from a data perspective rather than from a feature perspective. I sat through a requirement meeting for which the outcome was to go and hammer out a database schema that would provide the necessary tables for the application. They were literally conversing with the customer in terms of what data should be present in the database.

The development team has four people besides me. I would wager that even if they doubled their team size to ten, they wouldn’t half as productive as a team of four (good) agile developers who did TDD, continuous integration, and short-term iterative development.