I think most databases are happy to update views that only involve a single table. But when you involve multiple tables, you have to provide a rule of some sort to tell the DBMS what to do when it can’t necessarily figure it out. Apparently Oracle will try to do an update on multiple tables, but the update will fail if there are issues. But as of Oracle v7.3, you can update views on multiple tables by using INSTEAD OF triggers.
In his BuildLanguage Bliki Entry Martin Fowler says:
“Simple builds are easy to express as a series of tasks and dependencies. For such builds the facilities of ant/make work well. But more complex builds require conditional logic, and that requires more general programming language constructs - and that’s where ant/make fall down.
…
[I’ve] concluded … that a programming language is more the way to go and [that ant is] not a good UseOfXml.”
I have to agree that there have been many times that I have wanted to just use a programming language to do my builds. I also agree that XML is not the best format for presenting a human-readable flow of events. Using a simpler format, many Ant tasks could be compacted down to a single line, thus allowing you to see more meaningful information without having to mentally parse all the XML.
But, working in a shop that is set on standardizing things and then sticking to them across all the projects, it is difficult to convince the developers to get past popular and hype technologies. Because Ant is so standard in the Java world, and it is fairly well supported in IDE’s, I would probably choose Ant as a first choice for most projects.
I have used the Ant-Contrib Tasks which provides a set of supplemental tasks for Ant such as iteration, conditional logic, and try/catch logic. Using the Ant-Contrib tasks, I have been able to create small and simple build scripts that would normally have been significantly larger. I have also created a set of common targets that I reuse frequently and pulled them out into a seperate file that I include using an XML entity.
I’m definitely interested in trying out Rake, a Ruby based build environment that Fowler talks about in the same bliki entry.
Extreme Programming is a horrible name masking a great idea. People don’t want to have anything to do with it just because of the name. I think that is why the term Agile has become so popular now.
Extreme Programming is not so extreme. The extreme ends of the software methodology spectrum are no methodology and very heavy-weight methodology. Extreme Programming doesn’t get its name for being an extreme in the spectrum of methodologies. It gets its name from taking the practices that work well in software development and putting extreme focus on them. Taking the practices to an extreme so to speak.
For example, the practice of periodically reviewing code is a good thing. If we take that to an extreme, we constantly review code. The constant review of code derives the practice of pair programming. Testing is good, testing up front is great, and always testing up front leads way to test-first development.
I’ve done two large rewrite projects and I have been involved in a several smaller ones. I have learned over and over again that a complete rewrite is the most difficult, most risky, and most costly approach.
My current client has a project that was moved from another department into the one I’m working for because of business (i.e. political) reasons. The existing application was written in Perl/CGI/Oracle and might be described as a “hack”. The database schema was not normalized, and they managed security through an archaic scheme of assigning blocks of ID numbers to people. From what little I understand about COBOL, I would guess that this was a COBOL-like strategy. Besides the interface being confusing to start with, it also required every user of the system to learn this complex system of access through magic ID numbers. In short, the system was very procedural, hard to maintain, and unintuitive.
The department I’m in manages most of the Web applications for my client, and they almost exclusively develop in Java. So, somhow, the requirement for taking over maintenance of the project evolved into a requirement for rewriting the entire application in Java. Now, I’m definitely a fan of programming in Java, but this was going to be a fairly costly and lengthy project to undertake, and there was no way that we would have met the deadline.
Despite our disdain for the poor craftsmanship of the existing system, the customer was practically begging us to preserve the system the way it was, because they understood the ID based system well. They didn’t want drastic change. I sat down with a few guys from my department and we layed out the full spectrum of options:
1. Rewrite the whole application in Java, get rid of the ID based security and make the application OO, normalize the database schema.
2. Leave the database as is, rewrite the application in Java, but mimic the existing functionality (exactly).
3. Bring over the existing application as is (in Perl) and deploy it on our local servers.
We chose strategy 3, because all the customer really wanted right now was the exact same functionality that existed. Even though we were happy to come up with many improved and OO ways of reimplementing their existing system, we just didn’t have the time.
We had some discussion about how we would handle things moving forward. If we chose option 2, we would have the same poor quality system, but in a language we could understand. In fact, a good strategy would be to deploy the existing CGI system, then start mimicking each existing function of the system, one at a time, but rewriting it in Java. We could have all incoming requests pipe through Java and let the Java code handle what it can, and defer the unimplemented Java features to the existing CGI application. We would basically iteratively move from option 3 to option 2. Thus, the database and functionality would essentially stay the same.
The nice thing about this approach is that we wouldn’t have to maintain any of the CGI code (as we would if we tried to go from option 3 directly to option 1). After we had all the code in Java, then we could start refactoring code and normalizing the database. At this point we would essentially be moving from option 2 to option 1.
This seems like a solid strategy all around. From a user perspective, small incremental changes to their interface to a system seem to be accepted much easier than an overhaul. From a development perspective, development can be more iterative, less risky, and the cut-over would be easier to manage. And a customer perspective, there is less risk.