After reading Martin Fowler's book on Refactoring I've been a big fan of the practice. We all know that adding in tests to insure the refactoring doesn't change the results is essential.
But this last week the real world crept into our world of programming paradigms. We refactored a complicated section of code to make it simpler, more readable, and faster - a big win; except that after the code was fielding, one of our customers reported a problem.
Their use of our product actually depended on a bug in the old version. Refactoring the code fixed the bug and caused our customers grief.
I'm still a big fan of refactoring and continue to do it, but now I'm a little wiser that refactoring carries more risk than I'd thought before.
I'm blogging about programming, but ... hey look over there - it's something shiny!
Tuesday, November 24, 2009
Friday, November 13, 2009
Simian - a code duplication finder
Today I downloaded simian, a code duplication detector. It's very easy to download and run. Simian detected a few chunks of duplicated code, which need to be refactored into a single method, or pushed up into a parent object. Simian is worth a quick download to test your code. Eval copy is available for free.
C:\opt\simian\bin\simian-2.2.24.exe -reportDuplicateText -threshold=5 *.cs > simian.txt
Wednesday, November 04, 2009
Agile Austin - Domain Driven Design and the Naked Objects Pattern

Last night at Agile Austin Eitan Suez explored the relationship of Domain Driven Design and the Naked Objects Architectural pattern to a packed house of 60 people.
The thing that struck me the most was how using the Naked Objects concept of having the objects themselves create the GUI forces a Ubiquitous Language on the developer since the user will see the object and method names on the screen.
Eitan gave a great example by having the jMatter framework autogenerates a permissions table with objects and their actions on the vertical axis and the types of users on the horizontal axis by reflecting the code and dynamically discovering the objects, their methods, and the types of users.
Thursday, October 29, 2009
When Will We Have Enough Computing Power?
At the last Java User's Group meeting here in Austin, Gary Frost mentioned that if he took his $300 Gateway computer with its $300 graphics card back in time 6 years, his computer would be in the top ten fastest super computers in the world. Which got me thinking, "How fast do computers need to get?".
Well obviously a lot faster. I'll be happy when computers can do either of the following (I'm not picky):
1. Store every person's DNA and their medical history. That's 3 billion base pairs per person times almost 7 billion people gives 2.1 × 10^19 base pairs or about a Zettabyte. Then compare and contrast every person's DNA with their illnesses with everyone else and produce a report showing which diseases are related to which DNA differences. For example, asthma could be related to any of 307 combinations of 24 genes being different. Then we should be able to design drugs to compensate for the "defective" genes, or perhaps tweak those genes with a small bit of DNA from a friendly virus.
Storing a Zettabyte seems reasonably straightforward, diff'ing all the genes will take enormous computing power- but that's the power we need.
2. Predict the future health issues of a fertilized human egg based on its DNA. We would need the power to replicate division of all the cells grow the egg into an adult and simulate the running of the biology in each cell and predict the health issues.
Well obviously a lot faster. I'll be happy when computers can do either of the following (I'm not picky):
1. Store every person's DNA and their medical history. That's 3 billion base pairs per person times almost 7 billion people gives 2.1 × 10^19 base pairs or about a Zettabyte. Then compare and contrast every person's DNA with their illnesses with everyone else and produce a report showing which diseases are related to which DNA differences. For example, asthma could be related to any of 307 combinations of 24 genes being different. Then we should be able to design drugs to compensate for the "defective" genes, or perhaps tweak those genes with a small bit of DNA from a friendly virus.
Storing a Zettabyte seems reasonably straightforward, diff'ing all the genes will take enormous computing power- but that's the power we need.
2. Predict the future health issues of a fertilized human egg based on its DNA. We would need the power to replicate division of all the cells grow the egg into an adult and simulate the running of the biology in each cell and predict the health issues.
Tuesday, October 27, 2009
Austin Java Users Group

Random Notes from the meeting (entered via my shiny new IPhone):
Big Mike is starting a Certification group.
Gary Frost from Amd talked about OpenCL, the Open Computing Language. This provides binding to Java via C for running parallel operations on Graphics Processing Units. Gary's demo showed the n-body problem being accelerated by using the GPU to do calculations, while the GPU was also updating the screen.
The demo was very impressive, but the OpenCL seemed a bit clunky. I think the masses of programmers will need a much smarter compiler to inspect the java code and imply what the GPU can do in paralle.
The second part of the meeting Deb Ayers talked about Oracle's Enterprise Service Bus (ESB). She said ESB is a natural progression from client Server. Many of her clients don't use soap, just Plain Old XML (POX) over http.
For a dozen services you don't need an ESB, but some Telcos have hundreds of services and need an ESB.
Monday, October 26, 2009
Xeno's Paradox and Software Delivery
The ancient Greek philosopher Zeno of Elea composed a paradox to support his teacher, Parmenides's view of motion and change in the universe. His story is about a race between Achilles and a turtle. The turtle gets a small head start, but before Achilles can overtake the turtle, he must catchup with the turtle. Once Achilles has caught up, the turtle has moved forward, so Achilles must move a little further to where the turtle is now. But by now the turtle is ahead and Achilles must again catchup etc... so Achilles never really reaches the turtle.
I've noticed this same phenomenon in software development with regard to last minute features being requested to be thrown into the release. With three days to go before release, we get a small 4-hour feature request to be added. Then two days before the release another smaller item - really tiny, wouldn't take much effort at all - just two hours. One day to go, and another almost infinitesimally small item to be added - it will just delay the release by one hour and it's really needed.
In Zeno's world, the software will never get released.
I've noticed this same phenomenon in software development with regard to last minute features being requested to be thrown into the release. With three days to go before release, we get a small 4-hour feature request to be added. Then two days before the release another smaller item - really tiny, wouldn't take much effort at all - just two hours. One day to go, and another almost infinitesimally small item to be added - it will just delay the release by one hour and it's really needed.
In Zeno's world, the software will never get released.
Wednesday, October 07, 2009
Subscribe to:
Posts (Atom)