Dealing with technical debt

codeartisan: Jon Moore: Cracking down on technical debt:

Generally, as the folks with the technical ability to recognize it, it is the development team’s responsibility to try to avoid accruing technical debt while producing product. Failing that, it is their responsibility to recognize/document existing debt and to advocate for its removal. However, note that there are often symptoms of technical debt, such as those I’ve listed above for architectural debt, that can be recognized by non-technical folks too.

On the flip side, business folks / product owners need to be able to trade off short term wins that accrue technical debt vs. taking longer to produce a product with less debt. Communication with the tech team is of vital importance here; undoubtedly there will be times when a short-term win will be important (especially with a first-to-market situation), but it needs to be accompanied by a plan to eliminate the accrued debt. i.e. Treat your technical debt like credit card debt that should be paid down ASAP, and not as a long-term mortgage.

The interest on your technical debt is probably not tax-deductible.

Very much related to my earlier post about Agile gone wrong.

lang:groovy – extend your Spring app with scripting

The Spring Framework offers many ways to ease application development and maintenance, but one that gets my interest really going is its dynamic language support.

codehaus: Dynamic language beans in Spring

codehaus: Groovy and JMX

raible designs: Using Dynamic Languages with Spring with Rod Johnson and Guillaume LaForge

organic thoughts: Spring Meets Groovy!

An email I was happy to send….

Due to down time that my users were subjected to – by a decision one of your staffers made in shutting down access to our database – I have migrated the sites and domains I maintain that were hosted and managed at New Dream Network and Dreamhost to a more robust and secure solution.

Previously, when your staffers worked with me to diagnose and solve a high CPU situation, they showed patience and willingness to find a solution to pass on your other customers. Dreamhost impressed me then. I was very much ready to sing its praises.

That patience and customer care was entirely missing in this episode.

Without warning there was the decision your staffer made to shut us down. He sent an email to me upon doing so. And then for the next 24 hours there was no reply to any emails I sent to you for details.

Adding serious insult to injury was the removal of all access to my database, not permitting me to diagnose the problem, or migrate to a new host with up to-date data. One of your staffers told me it was my responsibility to have a back up. Well duh.

I had come to expect better from Dreamhost.

I hope you can rectify the problems you are experiencing with your customer care. I hear more and more from others similarly dissatisfied.

Please cancel my account immediately.

– Karl

Philly Future Status: In Transition

DNS is still propagating so there are two status messages to pay attention to on Philly Future. Each alerts you to whether you are using the new Philly Future, and can resume posting and commenting, or the old.

Hopefully by noon we will be in better hosting environment, one that is more reliable, better performing, and can handle the growth in features and in scope I’ve been wanting to tackle.

Philly Future Status: All clear

Let me put this diplomatically (for now): I am in the process of resolving Philly Future’s hosting issues and expect, by morning, for Philly Future to not only be clear of the downtime that was inflicted on us, but for Philly Future to be blazingly fast as well. I expect there will be few lingering issues to resolve, but over the next few days, we should be able to tackle them and come out of this better than ever.

Philly Future Status: Dreamhost has shut us down

Yesterday, March 11th, at 6:23 PM, a Dreamhost staffer alerted me that Philly Future was incurring too much database load and that they were disabling it:


I am sorry but I had to disable your database (it was single-handedly killing the database server – the load was around 20 and is now down
under 1 (4 is optimal) after disablement.

We can re-enable it if you can assure us you’ll take proper steps to curb the usage (you need to be sure you are indexing things if you weren’t and perhaps re-evaluate the efficiency of your code).


Immediately upon getting the notice we emailed Dreamhost our intent to help them resolve any issues they may have.

As of 12:03PM EST I still cannot access our database to attempt to improve performance or do a dump of it to migrate us. I have been emailing them all night.

This situation comes as a surprise since back on February 3rd we received a thank you from Dreamhost stating we had successfully reduced resource utilization:

You have successfully reduced your resource usage on machine limbo-spunky.

Therefore we have moved your account (#109016) back to its original home machine foothill.
Thank you for your efforts and we are glad to have your account in good standing again.

Moving you back to the original server will change any IPs associated with your web services. Please get the new ones if you set up any custom scripts or DNS that relies on the old IP to function.

Happy Dreamhost Support Team!

While we looked for and prepared a new hosting solution, Dreamhost’s staff worked with us to reduce our CPU utilization to an acceptable level over the course of January and as you can see, we had a successful resolution.

That experience strengthened my trust in Dreamhost, I came away impressed by them, and it enabled me to not worry about our hosting situation while my daughter was being born.

I assure you there were *no* warnings and *no* indications of a current problem.

I want to apologize to our community. This is an unacceptable situation that we hope to have resolved sometime today.

Thank you for your patience and understanding.

More updates as they come.