Category Archives : News

Why do dynamic languages make it difficult to maintain large codebases?

Dynamic languages have costs associated with them that static languages don’t. Let me begin by saying that it is hard to maintain a large codebase, period. Big code is hard to write no matter what tools you have at your disposal. Your question does not imply that maintaining a large codebase in a statically-typed language is “easy;” rather the question presupposes merely that it is an even harder problem to maintain a large codebase in a dynamic language than in a static language. That said, there are reasons why the effort expended in maintaining a large codebase in a dynamic language is somewhat larger than the effort expended for statically typed languages.



Ryan Seifert‘s insight:
This article touches on a topic I have been wrestling with. I keep returning to a rule of thumb: if it is a prototype, under 300 lines of code, or a single (or very limited) use program; dynamic language is easily the best choice. There is a reflection point where static languages make maintaining code bases easier; but that point is much harder to define.

I find it interesting how some large projects written in Javascript have chose to attack the increase codebase issue. We have seen inclusion of type-checking (Typescript), modules (jQuery et all), and much stronger test suites. Many of these techniques are common in static languages and have been used to great success in maintaining codebases.

Unfortunately, the article does not touch on if and when a module rewrite would be useful. At which point does the overhead of leveraging a dynamic language incur a cost greater than a migration to a language easier to maintain or which a better tool set exists? The emergence of language agnostic testing frameworks have reduced this barrier substantially (assuming tests provide significant code coverage). I am interested in seeing if language migrations start to occur at a larger rate (perhaps as language-to-language conversion becomes more common). Quick, painless, and verifiable language migrations would be a great boon for any project.


Defense Against the Dark Art of Estimation Bargaining

Defense Against the Dark Art of Estimation Bargaining

Let me set the scene for you. Someone strolls up to you. It could be a manager, a customer, or even another developer. Let’s just call him Peter:

PeterHow long would it take to replace our billing system?YouIt’s pretty complicated, maybe a 8 weeks?PeterWe need it by the end of July.YouBut that’s in 2 weeks!PeterThis is really important, when is the soonest you can you get it done?YouWell we can shoot for 4 weeks.

How did you suddenly agree to do a 8 weeks work in 4 weeks?


This article hits close to home; I find myself in this situation almost daily. Personally, the most important take away is pushing the estimate until a complete scope of the project is provided. When I provided the estimate from the quick description of the scope included was a disclaimer on requiring the option to update the estimate later. In my experience, executing that disclaimer to update the estimate comes too late to change the schedule; you are then left to attempt to remove features or schedule overtime (paid or otherwise).

How do others handle these situations? Blocking until the full scope is provided is not always an option; at which point do you take a shot?

How To Spot The Legacy Code Writer

How to Spot the Legacy Code Writer

In Working Effectively with Legacy Code Michael Feathers defines Legacy Code as “Code with no tests“, which reflects the perspective of legacy code being difficult to work with. I’ll stick to this definition.


Ryan Seifert‘s insight:

This is a great article on how code evolves in an organization. A quick fix here; a small misstep there can easily accumulate to a difficult to maintain piece of software. Even if the initial code is wonderful; new techniques and unexpected features can cause the code to evolve into unexpected, and unwanted, ways.

While I agree on the conclusion of the article, attempt to leave the code a better place than you found it, there are certainly difficulties in doing so. I know that in my experience you will not always have the availability to refactor the system; sometimes you will have to leave it at the current status quo. What I have found that works is to start to keep track of the more problematic areas and keep estimates on how long a refactor for those areas will take. The next new feature or update to that area, you can include the refactor time (be sure to flag it as non-billable if necessary) and simply perform it during that project. The refactor is included in the schedule (along with the enhancement) and should not cause any unexpected delays (which a surprise refactor could).

FCC Comment Page Buckles To Its Knees After John Oliver Asks Everyone To Comment

FCC Comment Page Buckles to Its Knees After John Oliver Asks Everyone to Comment

On Monday morning, we wrote about John Oliver’s brilliant report on net neutrality, which ended with a stirring “call to action” for internet commenters to tell the FCC why it should preserve a free and open internet. If you somehow…

Ryan Seifert‘s insight:

I can’t say I have ever watched the show before now; but I am a fan now. The segment really did wonders on explaining the issue and providing some much needed background on the problem now. Even better are the results; with the outcry crashing their page (and locking their phone lines).

If you haven’t voiced your opinion to the FCC on this; please do. Keeping net neutrality is very important to ensuring new companies and technology stay stateside.