Slashdot Mirror

"Constructor-based Programming" is approximately the same as Dependency Injection which is related to Inversion of Control which means if you program in Java, you should look at Apache Avalon, PicoContainer, and/or the Spring Framework. Enjoy!

Nice to see some actual content on Slashdot!

By the way, this reminds me of the recent article on Domain Specific Languages over on Martin Foweler's website. Another aspect of programming worth investigating.

I smoke two joints before i smoke two joints /

and then i smoke two more.

Automation can save significant amounts of time and money if the project [...] Has a large enough number of regressions to make the expense of automating less than the cost of all of the regressions.

On my last few projects, I did both automated unit tests and automated end-to-end tests, right from the beginning of the project. Developers are the ones in control of the unit tests, but I like the product managers and/or QA to be in control of the end-to-end tests.

In my experience, having test suites like this makes development go much faster than it otherwise would, even with very high-quality developers. And the payoff is ongoing; fully automated QA tests mean that you can change the system with complete confidence, releasing daily if you like.

My experience matches what Martin Fowler talks about in his blog entry on very low defect projects, meaning less than one bug per month.

No methodology is perfect for every team and project.

Absolutely, and the best approach is to pick and choose ideas from various methodologies that best suit your project and team.

There are a couple of ideas that XP encourages that I think can be beneficial to a wide range of projects.

Unit testing and testing-first is an approach that I think is a great way of testing your testing. The programmer writes a test, and then writes enough code to pass the test, then they write the next test, and enough code to pass that, and so on. This is an excellent approach because it ensures that code is well tested, and its less of a chore for the programmer because its all part of the coding and the problem solving process, rather than the thing you have to do after you've done all the interesting stuff. There are various unit testing frameworks to support this.

I also like the idea of continuous integration. Where every time a change is submitted to source control a complete build of the system is done, all unit tests are run, and any other checks are completed e.g. coding standards etc. The success of this is reported back to the programmer so any errors can be fixed.

XP was built on the knowledge you just mentioned: That the Q&D solution is necessary, and that if you try to follow set procedure (or the "waterfall model" as it's called) where you have a requirements, design phase, implementaion phase, testing phase you will most likely fail.

Basically, what XP is all about, is to acknowledge that the specification is useless, beacuse after a couple of years when the project is finished, the end result doesn't look anything like the sepcification anyway. At least if you want to survive in a dynamic market. We have all seem that in the real world, the requirements change during development, and if they do, you need to go back and change the spec, and then possibly reimplement large parts of the code.

So, how do you go about solving this? Well, first of all you have to understand and believe in a couple of mantras:

• The implementation is the specification
• Refactor mercilessly
• Do the least thing that could possibly work
• Test driven development

Here is the list of development rules.

The implementation is the specification

This means that instead of writing a specification before programming begins, you let the application evolve (very similar to most Open Source projects actually) and if the requirements change during development, you change the code to adopt.

Refactor mercilessly

This is absolutely nessecary in order for the previous point to work. What it means is that you should not be afraid to change the layout of working code, to make it easier to add new features. With good refactoring you don't need a complex design in the beginning, which means that you get to market more quickly.

I strongly recommend you read Martin Fowlers book Refactoring, it's a real eye-opener.

This leads us up to the next point:

Do the least thing that could possibly work

If you are thinking of implementing a couple of abstract base classes and interfaces to make your object design super generic, so that it can be used for a lot of differnt things in the future. For example implementing a plugin architecture in your file parser or somehting like that, you need to ask yourself the following questions:

Am I going to need this abstraction now? and If I need it in the future, will it be easy to refactor the code so it gets that functionality? If your ansers to there questions are "no" and "yes" respectively (which they usually are) then you should not do it.

Essentially: don't do anything until you need it.

Test driven development

All this refactoring, and no solid specs can be a bit scary, especially in the beginning. A common question that pops up is: "how can we guarantee that the code works if you keep changing it all the time?". The answer is: unit testing. The rule of thumb here is: Implement the test first, then you implement the code so that the rest runs. Whenever you are going to fix a bug, write a unit test that triggers the bug first, and then fix the code so that the test succeeds. You then make sure you run the ever growing test suite several times per day. It helps a lot in catching regression bugs.

For Java, I recommend JUnit.

Now, the biggest problem you face is selling XP to your PHB's. They will more than likely feel that they are losing control, and they will be afraid that their nice Microsoft Project documents will become useless (no one seems to remember that (almost) every single waterfall project will overrun both budget and time constraints). However, there is

It comes down to picking the right technology for the job.. and your team. JDBC, JDO, OR-Mapping, EJB, etc all provide good tools to complete the job.

Agreed, but in my opinion any application which needs heavy multi-user data processing (think OLTP) is better served with the more "traditional" way of doing things: let the RDBMS do the transactions and cacheing, because they do it best. Call me a data modeler or SQL buff you like, but I still fail to see the advantages in letting the "application server" do these kind of things.

About the only thing I see useful in EJB (vs. POJO+JDBC) is that they give you the networking infrastructure to make them remotely callable, so that you don't have to mess with RMI or the like.

A good article I read recently by Martin Fowler, "Domain Logic and SQL" covers some of these points, and reinforces my opinion that neither EJB nor any other O/R mapping tools are suited for heavy OLTP apps. Or am I missing something?

Martin Fowler has a very comprehensive book on refactoring - Refactoring: Improving the Design of Existing Code (On Amazon)

Just bought this book, so far so good... Here's a link to the Errata.

Try the book's site for a complete list of patterns, with diagrams and descriptions: http://www.martinfowler.com/eaaCatalog/

If you haven't implemented locks for an object model, then you haven't lived. Seriously, I can see a lot of people screwing this up with deadlocks galore. Locking up concurrent systems can be a nightmare.

Then just wrap all of your lock-sensitive stuff in Prevayler command objects. They've got that working fine, and it guarantees isolation.

Goodbye Crystal Reports, Goodbye English Query, Goodbye ANY Ad Hoc query support, because if you need anything different, you're going to have to write a lot more code to enumerate throughout your objects. Have fun.

Oh, please. If you really need SQL compatability, then dump the data occasionally to a data warehouse, which is where you should be doing unconstrained ad-hoc queries anyhow.

Or if it's so the programmers can peek at the live system, then put in something like BeanShell, which will let you see a lot more than just the persistent data.

Or you could drop an SQL interpreter into your system and present your objects as tables. Many of the pieces are already open sourced, so it would be pretty easy.

Indexing - I hope you have a good B-Tree library and are familiar with Indexing/Searching algorithms when implementing HARDCODED indexing. Oh yeah, have fun rewriting all of your query procedures when you decide to change your hardcoded indexing.

Can you really not think of ways to write these things in flexible ways? If that's the case, you could learn something about being a programmer. Pick up Martin Fowler's Patterns of Enterprise Application Architecture.

In all seriousness, this is a bad idea for 99% of projects out there. It's inflexible, unscalable, severely error prone, and timely to implement.

Perhaps you should try it before knocking it. As you are, in order, wrong, mostly wrong, wrong, and confused. It's no magic bullet, but it's a useful approach for some systems.

Another way to state: People who are good at brain-teasers are usually good at figuring out problems in real life. But rarely do the brain teasers mirror real life.

I observe that those said people are often good at minutiae of life but can never get their heads out of their arses long enough to see what is really happening in real life:-)

As for the grandparent comment about people being more important - isn't this exactly what agile "methodologies" recognise? Whilst I am not a convert to the lap dancing extremities of extreme programming, I do strongly agree with the underlying observations made with regard to agile development.

I particularly enjoyed Martin Fowler's knock off of the endless comparisions between software development and civil enginering. In a wide ranginging article he manages to capture just about all the hazy confused conclusions I've arrived at after 15 years in this industry.

Another way to state: People who are good at brain-teasers are usually good at figuring out problems in real life. But rarely do the brain teasers mirror real life.

I observe that those said people are often good at minutiae of life but can never get their heads out of their arses long enough to see what is really happening in real life:-)

As for the grandparent comment about people being more important - isn't this exactly what agile "methodologies" recognise? Whilst I am not a convert to the lap dancing extremities of extreme programming, I do strongly agree with the underlying observations made with regard to agile development.

I particularly enjoyed Martin Fowler's knock off of the endless comparisions between software development and civil enginering. In a wide ranginging article he manages to capture just about all the hazy confused conclusions I've arrived at after 15 years in this industry.

I work in a game studio where our last project had 6 months of pre-production time. We generated reams of technical design documents. The intention was good, but they were never maintained or even referenced after their initial creation. We just said "documentation is necessary" and it needed to be done. In production, the team wasn't on the same page. Every programmer had a task list they just milled through. The assumption was the initial requirements won't change. The result was ugly. The product was subpar and a couple months late. Everyone was miserable. It sucked.

I'm currently leading a new project here. We're 6 months into production and every milestone has been delivered ON TIME and accepted by our customer. The team is focussed on the current milestone, there isn't a lot of process to get in the way. The best part is, writing code is fun again. We don't have goals we can't accomplish. And we fully expect the product requirements to change during production.

I could get into specifics about our process. But I don't think it would be that helpful. I think specific methodologies like XP are guidelines to get you started. From there, you really should re-evaluate your process frequently (a fundamental excercise to be "Agile") and make changes as necessary. Kind of like optimizing your code.

The following links gave me all the information I needed to devise an initial process plan (which included TDD). But once it was put into practice, it naturally evolved into the process we have now (which doesn't include TDD)...

The New Methodology by Martin Fowler

The Agile Manifesto

Agile Software Development Ecosystems by Jim Highsmith

I also suggest reading the chapters on "thematic milestones" in Writing Solid Code.

As it's turned out these have been very valuable as we have started to use .NET in 2002.



Such a person should not be referred to on Slashdot.

Check out Martin Fowler's Enterprise Architecture Patterns, some of them can apply to any type of GUI. The MVC pattern does not just have to apply to single components of a window. But there is a difference between creating the GUI architecture for a CAD type program as opposed to a Business type program. For example: CAD programs can have thousands (or more) of objects on the screen at the same time; so modelling each as an object will bring your program to it's knees (using the Prototype pattern can help here).

You might try searching google for 'CAD GUI' or something similar; I've seen articles / web pages that discuss GUI's that are not database backed / business related, but I don't know the addresses off-hand.

On a sheet of paper, draw a line separating the paper into two halves. In one half write "UI Module" and in the other half write "Database Interface Module".

Actually, this is considered bad form in an OO design. The UI "Module" (classes) should only talk to the Model classes, while the Model classes may or may not talk directly to database classes. They may be mapped to database tabels thru an indirection layer.

There is some great discussion of this at Martin Fowlers website.

-Peace
Dave

Surely a tool that spits out UML-like diagrams of the current code would be very useful to spot architecture flaws introduced during the refactoring process.

However, I would point to something Martin Fowler said:

... some people find software diagrams helpful and some people don't. The danger is that those who do think that those who don't should do and vice-versa. Instead we should just accept that some people will use diagrams and some won't.

The fundamental benefit of continuous integration is that it removes sessions where people spend time hunting bugs where one person's work has stepped on someone else's work without either person realizing what happened. These bugs are hard to find because the problem isn't in one person's area, it is in the interaction between two pieces of work. This problem is exacerbated by time. Often integration bugs can be inserted weeks or months before they first manifest themselves. As a result they take a lot of finding.

One solution to avoid patching problem is to use continuous integration. It's an integration technique that builds your source multiple times a day, getting all the latest source code from the CVS tree, and building from that code. If anything fails, the offending developer gets warned. Mozilla uses the same thing, calling it TinderBox. It's one of the principles of Extreme Programming, and seems to work quite well at our company.

Except Jedi Knights are going to be exceptionally rare. Verant has addressed this topic time and again in its Developers' Forum. Give it a look some time.

Becoming a Jedi will entail a LOT of development time as well as many difficult side-quests, not to mention the fact that you'll have to construct your own light saber...

Code in general writes easier than it reads.

That's true about most code, but most code is crappy. As Martin Fowler says, "Any fool can write code that a computer can understand; good programmers write code that humans can understand."

The review mentions a void for beginning UML books. I think the void is filled quite well by UML Distilled by Martin Fowler and Kendall Scott. It provides an excellent, concise explanation of what UML is, how to use each UML artifact, and why you should care. Good for the beginner or those with short attention spans.

About over design in OO - check out YAGNI (You Ain't Gonna Need It) and other XP principles here. Or, take a look at this article, Is Design Dead?.

The Eclipse Project got a lot of buzz at the last OOPSLA conference. A follow-on to IBM's VAJ, it's intended to be a programmer's workbench and include current tools like a refactoring browser, continuous integration. Too bad it seems slashdotted.

1. Plain XML, without schemas
   XML is a markup langauge that is supposed to be human readable. Thus anyone can whip up an XML document that describes some data (e.g. documentation on software). It helps if you have standards to make the XML consistent.
2. Plain XML, with schema (or DTD)
   Creating schemas for all you different types of documentation is probably the first big pain in the butt you will deal with, but it is pretty essential to get a project like you describe to work. It helps by setting common standards which all participants in your org can use to understand the docs they are looking at. Now you also get some tool support for creating and validating your XML documents.
3. Database -> XML
   Store all your documentation data in a database and use common db tools to extract it and format in XML. Why bother? Tool support! Lots of software development project tools support using a db as a repository for the various work products (documentation and code and stuff). This also allows you to have somewhat easier methods for serving your content to interested parties with appropriate security constraints.
4. Repository -> XML -(XSLT)-> HTML
   Here we add the ability to transform the human-readable-but-cumbersome syntax of XML into html for viewing on a browser. The big effort for this sort of architecture is that you have to create the XSLT for all your different document types and you need some way of linking-to/searching your documents from the html into the repository. Some application and web servers help with this. I'm most familiar with the Java space, and Tomcat with various xml libraries can be made to do this.
5. Repository -> XML -(XSLT)-> XML -(XSLT)-> HTML
   This is the most flexible architecture in which pure data XML is transformed into an intermediate form which represents an abstract presentation of the XML and which is then transformed into HTML (or WML or PDF or whatever). The first stage of transformation you need one XSLT style sheet for each document type to convert it into the presentation XML. Then for the second stage you need one stylesheet for each display format. The big advantage here is that if you need to publish to a new document format, you don't need to re-write _all_ of your first stage transformations, you only need to add one new second stage transformation.

• Bill Joy
• Martin Fowler
• Grady Booch

If all you are doing is drawing class diagrams with some inheritance relationships, a few aggregation or association relationships, then yeh, UML is by far overkill. But if you actually have a complex async system, with concurrent events and distributed processing, you'll learn to really appreciate the sequence diagram and the activity diagram.

Even with class diagrams, if you care about multiplicity and aggregation vs. composition, then you'll appreciate the UML.

On the other hand, if you are a Cowboy Coder, or if you're as allergic to paper and ink as Kent is, then you'll do fine with napkins and felt-tip pens.

Far and away the greatest thing about the UML is that it is a widely-used and understood diagramming notation. Your alternate is some weird propriety notation that probably makes no conceptual sense *cough* bliner *cough* used where it isn't intended, or some strange diagram thrown together in Visio by the graphic-design-impaired system architect with the symbols he thought looked pretty.

You might pay particular attention to his habit of writing unit tests before he does anything.

It's worked wonders in my organization, and I suspect that the "war room" approach lends itself to similar types of productivity gains.

Or how about when you have to deal with legacy code written by someone who didn't care (or couldn't do better)? Sure it would be nice if you could rewrite the code to be elegant and such. But... the more code you rewrite, the greater the chance of one of those typos or such. And in the real world, it doesn't fly when you say you introduced a bug while rewriting the code.

So how would your statement above relate to such things as Refactoring which aims to do what you describe in the real world? It's an integral part of Extreme Programming methodology which seems to be somewhat popular amongst the Open Source software developers.

Refactoring has been, according to author Martin Fowler, practiced by the best software engineers for decades (long before XP came around). Are you saying it won't fly in the real world?