davesims

I've had a good number of conversations actually with some NASA FSW coders, and in general they're open to these ideas. NASA has a project with architectural and structural goals pretty well-aligned with what we set out to do at Kubos: https://cfs.gsfc.nasa.gov/Features.html

The biggest challenge is to prove that it works. The space software community historically is very conservative and risk-averse, and mostly for good reason. As Kubos (and hopefully others) get more flight heritage with Rust on the flight segment, it'll be a much easier sell.

That's the biggest obstacle I think. Someone will have to break the seal and establish that "Rust in Space" actually succeeds consistently, then larger "trad space" organizations will follow.

We came to the same conclusion at Kubos, and moved from C to Rust for most of our flight segment/application code (embedded Linux on the satellite OBC).

https://www.kubos.com/

Have you made any decisions about Bryana's responsibilities that were motivated by her gender, rather than her personal strengths?

Nope. Fortunately for me, while I was in a position to make those decisions about Bryana (I've since changed gigs), her own excellent performance was the only thing I had to think about.

Look, I'll let Bryana's own career speak for itself, which I have no doubt it will, but for myself I'd have confidence putting her in front of any audience on any topic she feels comfortable talking about.

One other thing, if you know anything about how conferences work, CFPs/speaking roles are something managed by the conferences, not companies. Questions of 'token' or otherwise are best posed to the individual organizers of the conference in question.

only your decision to offer her opportunities and incentives based on her gender which her post implies were not also available to equally qualified male members of her team.

Her post only implied her own personal, subjective and utterly understandable anxieties on that point. My response was at pains to put both her questions and anyone else's to rest. She earned everything she got, and the comprehensive respect she received from her peers was without qualification. Never mind gender, she coded way beyond her years of experience. The main thing with managing Bryana was to get out of her way and let her do outstanding work, which she did.

If you want to put the conversation to rest, simply clarify that point.

Was there something ambiguous to you in my statements here?

* Bryana's performance _across the board_ was top-notch, _without qualification_.

* ...she..._earned_ every single bit of responsibility she ever got.

* We just evaluated the [interview] performance and hired the best dev for the position, _end of conversation_.

As someone who was directly involved with hiring & managing Bryana let me set one aspect of this conversation to rest: Bryana's performance _across the board_ was top-notch, without qualification.

She commanded, and continues to command, respect from her peers for both her technical contributions on a very challenging tech stack, and product savvy in an extremely complex business domain. I was on her interview and there was no question of moving bars. It didn't even come up, because she was so very well-prepared. We just evaluated the performance and hired the best dev for the position, end of conversation.

On the job she spoke with authority and confidence in standups and earned every single bit of responsibility she ever got. Mention her to anyone who's worked with Bryana and you'll get the "eye roll of respect." She's so talented there was a minor running joke with a couple of us that we should keep a countdown clock of "minutes till I work for Bryana."

I only wish that early in my career I could have been half as well-rounded and with a fraction of the aptitude, product savvy and technical depth Bryana has.

This is pretty unhelpful as this (your) submission wasn't discussed at all.

> Note that the word "claims" shows up not even once.

That word actually shows up exactly once in each episode.

> In the first episode, they insinuate that IV doesn't pay inventors like they claim. In the second episode, turns out that they do pay quite well, but oh look! that inventor is totally a schmuck for ripping off his coinventors! (Is he really the kind of inventor that IV is paying?!)

Yes, IV paid Chris Crawford -- the one example given by IV of an "inventor" who made money -- for a stake in a patent. That's what IV does. They buy patents or percentages of patents. TAL never claimed otherwise. Crawford retained a percentage of interest in ongoing revenue obtained in court, which was distributed accordingly.

As to whether Chris Crawford is a schmuck and ripped off others, or whether the invention in question was even his to sell or was his idea to begin with, I think this court transcript from a case that he lost, speaks for itself:

---

Attorney: So the first paragraph of this document reads, quote, "This proposal, it is in response to Jack Byrd's idea to provide automated offsite backup services for PC users." And aren't you in the second sentence saying that Jack Byrd had an idea to provide automated offsite backup services for PC users?

Chris Crawford: No. What I'm saying is that Jack Byrd had an idea of me pursuing the automated offsite backup services that I had--

Alex Blumberg: Chris Crawford then launches into a rather surprising explanation for how the sentencing that this business was, quote, "Jack Byrd's idea," doesn't actually mean that the business was Jack Byrd's idea. His explanation? He was using the apostrophe S incorrectly.

Chris Crawford: As far as the apostrophe S-- and I'm still not clear if you're trying to derive a specific meaning with respect to the apostrophe S--

Alex Blumberg: Of course, what would a sentence reading, "in response to Jack Byrds idea" even mean if the S was plural?

Attorney: I'm asking you, though-- you certainly know what the use of an apostrophe S means, do you not?

Chris Crawford: [SNIFFING] As I've written documents over the years, there are times when I use an apostrophe S, and it seems like I'm supposed to use an apostrophe S. But I have to say that my grammar is not strong enough to tell you right now with clarity when an apostrophe S is used.

I think it's a bit of a category mistake to call filesystem or database data 'global state' in this context. Virtually every application has external persistence of some kind and some way of referencing that persistence. Technically those references -- variables or classes that manage connection pools or IO utilities, etc. -- can be called 'global state', but that's generally not what the CS literature is talking about when it says 'avoid global state'. The Evil Global State of CS lore generally refers to globally accessible static or class-level values that refer to in-memory structs, objects or values of some kind, in the stack or heap, rather than external persistence. Filesystem and database access is usually taken for granted, and is ceded as the unavoidable level of 'global state':

http://c2.com/cgi/wiki?GlobalVariablesAreBad

State, in general, at any scope, can make things difficult no doubt. But global state is classically bad because it's hard to reason about across large chunks of distributed code, pollutes namespaces, creates concurrency nightmares, etc. Reducing the scope of state to a manageable range of, say, less than a dozen lines of code, into short-lived references, is clearly far better than the alternative and a reasonable approach in the vast majority of cases. Calling it 'poison' ratchets the rhetoric way beyond the gravity of the problem. No, local state is not considered harmful.

What it seems OP is really talking about in practical terms is pure stateless programming, where the application has no implicit or explicit references to a value whose authoritative data resolves in main memory. If you were to tell me the only state you have in your application is Filesystem or database data, "just beyond the edges of our program logic," I'd say you'd basically achieved the fabled 'stateless' programming ideal, long held as a kind of Holy Grail of functional application development, and as OP points out, that's not often achieved even in the strictest functional environments.

I don't want to diminish the points made, the article was instructive to me as yet another anecdote about the perils of shared mutable state at any scope. But the fundamental principle, that one should avoid shared mutable state as much as possible -- which is the upshot of the essay -- has been axiomatic for quite some time.

Yeah I'm trying to get my head into how this would come about. It would be along the lines of how agile thought leaders shifted the notion of 'man hours' to 'story points', or how we stopped measuring LOC as a feature of productivity.

But there would have to be some cultural and language support for an entire idea around what a codebase is. The idea that it is an object that can possess the property of velocity will take a bit of enculturation. But the software/agile community has done it before, so...

"Code quality matters when you have a team of people developing and maintaining software over a long period."

And for me, 'a long period' is anything longer than a month, or more specifically, the time period it takes for me to have to change any code I've already written in order to deliver new business value to a customer.

...and just noticed your 'six weeks' estimate. We're on the same page here it seems. :)

Thanks! The more I think in this direction the more I think we need to really push this language or something like it. As much as I love the idea of 'craftsmanship', etc., when business stakeholders hear that language and similar ideas, fear grips their heart. We can do a better job creating awareness of the dollar value of bad code by changing the way we describe it in a credible way.

Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code.

Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death.

Here's an example from this essay:

"There is a reason good code is considered to be a form of poetry. It's elegant, clean, easy to read, and fun to write. These are all exceptional qualities that we should strive for every single day."

Try telling a product manager or CEO or other stakeholder how 'clean', 'easy to read', or -- God forbid -- "fun!" your code is, and watch their eyes roll back in their head. (I exaggerate for effect.)

These ideas make sense to us as developers because that's what we spend our entire day doing: considering, reflecting and thinking about code. But I think what we should be talking about is the inherent speed of the codebase. I'm not talking about my velocity as a developer, or the velocity of the team and how many story points they deliver per sprint, but the inherent velocity of the codebase as a function of its technical debt. Codebases, from a business standpoint, should not be "clean" or "dirty", but rather "fast" or "slow".

Technical debt should be surfaced to the stakeholders using language that conveys the dollar value, the fiscal liability, of technical debt. The most accurate way to describe that and show how debt is slowing your team down, is to talk about its inherent speed.

"Our codebase is getting slower" makes business sense to a Product Manager. "Refactoring this will make our codebase faster" is a phrase that conveys the worth of initiatives that otherwise seem to have no immediate effect on the bottom line.

All of the tools and agile methods we have talk about velocity in terms of what a team is delivering, and can parse that down to the sprint and developer level. But in my experience, the most significant contributor to a team's relative speed is the (intertia|speed|velocity|momentum) of the codebase itself, as a function of its technical debt. I think we need to start using language that intuitively and constantly surfaces the dollar value of technical debt to the stakeholders, so that "just ship it!" no longer sounds like a sound business strategy.

TIL Microsoft makes (a lot) more money on Android than Google does.

(Machiavelli's teachings) are not fit to be quoted in a discussion of how to conduct a democracy.

Sorry, I should have qualified that, because I wasn't endorsing Machiavelli, only acknowledging his influence on our current context.

You're right about the violent times of The Prince. You're wrong about two things: the notion that it is removed at all from our contemporary environment (such brutality has not been surpassed in extremis in the last century alone? Please...), and the idea that the fundamental turn from the idealism of Plato and the ancients to the pragmatism of the moderns was not prefigured and in fact architected by Machiavelli. The philosophies of Real Politic and Neo-Conservatism (at least) are fundamentally Straussian/Machiavellian in origin.

All I can say about the rest of your points regarding the mentally ill is, I wish mental health was the world's biggest problem as you seem to think it is. But in this discussion it's a complete non sequitur.

The difference between your declarative and mine is scope. Mine focused on one person's statement; yours was a sweeping historical generalization.

"falsifiable observationally verifiable prediction..."

Go back and read The Open Society and Its Enemies or Objective Knowledge. and you'll find this statement constitutes a fundamental misreading of Popper.

Never mind the fact that Popper was basically wrong and the notion of 'falsifiability' is a non-starter when it comes to practical application of political theory, Soros notwithstanding.

"History and politics and sociology classes are not..."

"its already just a piece of paper..."

"You won't be permitted to change anything..."

"if voting could change anything it would be outlawed..."

"You'll be given..."

"This is the stage..."

"The purpose of a democracy is..."

"its a blueprint..."

A litany of declarative bromides, delivered with pseudo-authority and strung together without forming a coherent thought, call to action or proscription for remedy. Such could only ever be pointless, nihilistic, and and anarchic.

Demagoguery in the making.

It's a reasonable question, but is it practical? 9/11 only killed a fraction of the number who probably died in the last few days in the recent typhoon, but the effect was to bring the entire country and economy to a halt.

The US would need statesmanship beyond that of Churchill to galvanize and harden society against those eventualities.

Moreover, in an era of dirty bombs, chemical weapons and even full nuclear devices, the consequences might not always be merely a "handful of casualties," and the grotesque effects of certain weapons, particularly on children, would be images that would be highly likely to incite increasingly aggressive responses.

The US historically is not a society that is accustomed to the idea of being under any kind of siege, nor of allowing its families to remain under threat of any kind. That's not the underlying narrative, and it's just not in its DNA.

This is exactly the question. If the channels of democracy still exist in any form (and the alternative is unthinkable), then we have to take control of them and put forth real statesmen to answer this challenge. The consequence of failing to do so is a society that steadily descends into complacency and despair.

EDIT: BTW, I've no idea why your comment is not higher. Anyone downvoting it is not paying attention imo.

Heh, now you're throwing Socrates' critique of Democracy at me? :)

Sure -- democracy is no guarantee. Referendums go wrong. Aaaand we're back to the Enlightenment political question of how best to balance the will of the masses (which can become a mob in the right circumstances, or an instrument of oppression to the minority) against the wisdom of representative government -- a republic. A sticky wicket indeed. The idealism here -- and I freely admit that it is based on a naive Modern optimism -- is that a transparent, representative democracy, rather than a direct democracy, corrupts more slowly over time and retains the highest possibility of self-reform of all types of governments.

I wish this were true, and I share your compulsion, not necessarily a rational one, to prefer compassion and understanding and detente to bellicosity and intrigue.

Unfortunately for both of us, the truths of Machiavelli are not easily defeated, least of all by something as saccharine as "make love not war." The most tyrannical and imperialistic societies in history, from Rome to Stalin, often began with variations on such noble sentiments.

"Care better for the crazy." In other words, anyone who means to do harm to the republic should be institutionalized? How? By force I assume. Who defines "crazy"? The history of international conflict unfortunately is not a story of the rational and benevolent vs. the "crazy and murderous", but of competing ideologies, scarce resources, and plain corruption.

The problem with such naivete is that it assumes the problem is theoretical, and merely needs the correct sociological constructions and psychological theory implemented by benevolent institutions.

But how do those institutions grow over time? Who governs them, and which of the many competing and contradictory sociological and psychological models do we apply, first of all to define and identify "crazy," and then to apply the appropriate remedy? Further, what concrete example of such an application can you offer as proof that such a program works consistently on the local individual level, much less the international level?

Further, can you show through examples how such an institution sustains and protects itself through means other than power and violence?

Well, it ain't exactly Tocqueville, but it does provide an interesting perspective on how the US is viewed abroad.

The thesis is simplistic though, and can be distilled along pretty obvious classic political theory: every society has to balance liberty against order, and decide how to deploy power to defend its borders. It's the essential question in classic political philosophy from The Republic to Machiavelli and everything that came after.

It's not enough to simply repeat the ancient truism that "power and fear are dangerous," which should be axiomatic by now, particularly coming from a German point of view, which has spent the last half-century-plus contemplating that exact question, from the point of view of having quite dramatically been both oppressed and oppressor in that time frame.

The broad question that needs to become visible and widely discussed in American politics right now is both classic and novel, and quite frankly we need help in guiding this discussion:

The classic question that needs to be resurfaced is, how does the US become self-conscious and more transparent about the specific boundaries we draw between protecting order and establishing liberty?

The novel question in the new post-9/11 context is how to manage that same balance in the ongoing battle for intelligence which by definition requires tremendous secrecy and daring.

It's clear that many both in and outside the US are profoundly uncomfortable with the current state of NSA surveillance and I agree. But what is an appropriate level of surveillance? How can US citizens take back control of that conversation and make deliberate decisions about that kind of society we want to be?

And that's really the underlying problem that I think the Speigel article was simplistically, indirectly getting at: citizens in the US no longer have the democratic power to make those decisions. But in order for the governing powers to trust democratic processes to make those policies, we need to become self-aware and articulate enough to advocate those policies, and bring up leaders that energize and focus that discussion with real statesmanship.

Statesmanship! Where is it? Can it exist in the current broken and polarized political environment?

To the degree that we still have some democratic processes in place we are responsible to say more than just, "Snowden is right!" We have to know what kind of society we actually want to be in this new context.

The enemies and threats are new, but the questions are ancient. We have not yet adapted old answers to the new context. And for that we need not only novel political theoretical solutions, but the strong statesmanship to apply them.

Reminds me of one of my favorite bits of rock criticism from the early oughts, Farm Report Wabi Sabi:

http://nypress.com/farm-report-wabi-sabi/

'Then my favorite fellow Bubba, Jesse Gutierrez, came by to swallow some beers. He told me that he’s been studying Japanese esthetics, and that what I was talking about was "wabi-sabi," the beauty of the humble and the imperfect. Wabi-sabi, declaimed Jesse, his thumbs hooked into the straps of his overalls, was developed to its height by 15th-century tea masters who found that the finish of Chinese Ming porcelain began to cloy. They started buying and exalting absolutely plain Korean peasant ware, stuff that was cracked, distressed, flawed. It reminded them of the beauty of nature, autumn leaves on a stone path.'

Actually this is incorrect -- the windows you're referring to were part of the earlier MDI version of Opera. In 2000 Opera 4 came out with tabs very similar to what FireFox would have in its first release four years later (and its predecessor Phoenix had in 2002).

I'm getting along in (coder) years, and I'll just throw this bit of advice and then yell at you to get off my lawn.

I've cycled through "this isn't my passion" about 5 times in 15 years. And what I'm learning, very late, is that it can take about that long to understand the true nature of "passion," and years to develop enough facility, experience and comfort with a particular skill or vocation before you actually understand what it means to be truly at home in something that has become a part of you, probably through years of cycling through thoughts of "this isn't my passion."

"Passion," or the lack of, can be many things. It can be a deep-down intuitive feeling that you simply Don't Want To Do This Anymore. It's OK to feel that in your early 20s, or 5 months into your first gig. But, my 2c, don't give too much credence to it. Real passion happens most often with things that have beaten you down 4 or 5 times and finally have been overcome 'cause you kicked back. "Passion" happens most deeply with something that you love like a hometown, warts and all. Where people know you when you walk across the square, know which parts to avoid, and who has the best coffee. Programming, and really any vocation you chose is like a city. It's many things to many people, and rewards best those who practice a discipline of place.

So, I'd say, hold those things in tension: your gut feeling that this may not be for you, over and against the possibility that any new vocation you pursue will present the same roller-coaster of emotion: feelings of incompetence and boredom and futility, followed on by euphoric feelings of revelation, victory and at-homeness.

The trick is knowing whether you're just on the front end of that cycle, and when your gut is really telling you this isn't for you. For that -- talk to friends and coworkers. A lot, over long periods of time. But don't just go with a gut feeling.

The challenge here, in my experience on both sides of this, is that a developer's deep domain knowledge of a large or large-ish app is essential to a 'work-sample' environment. And that's virtually impossible to duplicate even in the longest interview time frame.

Making decisions about managing technical debt, adding architecturally-significant changes, balancing good OOP with responsiveness, knowing the difference between future-proofing and conscientious coding -- all of those are both crucial (in many cases the most crucial) to day-to-day work, and also so highly context-specific that those decision-making traits are nearly impossible to identify during a technical exercise.

So for coding challenges, that leaves short-term tactical/analytic/algorithmic exercises, which in (anecdotally) 95% percent of cases cannot begin to approach a 'work-sample' environment. I've yet to encounter a technical challenge that would tell me much more about a candidate than basically how fluent they are with their tools, how well they know syntax and some general design principles, and what, for instance, their TDD (or lack of) workflow is like. Probably some insight into line-level analytic and algorithmic ability.

All of that is helpful, but -- Trust Me Here!! -- can also be very deceiving. The same coders that can knock those challenges out of the park can also be highly-proficient Debt Machines, all the more destructive because of their special genius for cranking out architecturally suspect code at a breathtaking rate.

To get into a real 'work-context' flow of a large app requires weeks, sometimes months, and only then can you get full perspective on how a given coder is going to contribute to your team on an ongoing basis. To get a feel for what that will look like in an interview, I've found I have to pretty much rely on the candidate's past projects, and informal conversations around larger architectural and OO principles.

Another perspective, not so flattering of the author:

http://www.washingtonmonthly.com/archives/individual/2003_04...

Nicely handled. Good for you, take your time Ryan. You've given so much quality free content over the years, the least the Rails community can do is hang back and let you figure this out on your own good time.

The Einstein example is a non sequitur. This isn't a technical, algorithmic or scientific problem that needs special genius. Where's the 3D rendering of Relativity that makes E=MC2 perfectly comprehensible for the masses? Or is that defeatist?

Neither is the problem with representation. We've had 3D visualization for years -- spaghetti flying at you in perfectly rendered HD 3D is still spaghetti.

The problem is not with the technology, but in the subjective perception of complex domains, and the real world fact that codebases tend to be more unclear than not, acquire massive amounts of technical debt, and even the cleanest codebases, in pure Uncle Bob and GOF-approved architectural clarity, present a cognitive domain that requires a lot of specialization to understand.

It's like saying -- what if the problem with understanding French is that we need better visual representations of French? Cool -- that might help the French and other Francophiles, but it doesn't remove the conceptual barrier and basic training required to understand the underlying language.

Likewise, if I presented you with a perfect 3D model (whatever that means) of my pub/sub solution built with a Reactor Pattern that messages N number of clients and takes asynchronous events from N number of other clients and persists the results of processing those messages in a sorting algorithm to a key-sorted Hash inside a NoSQL store -- you'd still have to have the conceptual vocabulary and experience to have any idea what was going on.

In other words, the issue is not an extrinsic problem that needs innovation, but a subjective problem of conceptualization that floats independent of language and implementation.

I love Steve Jobs' attitude and take inspiration from it -- he put user experience and elegance over the needs of programmers. But let's stay with Jobs for a minute. Because he was focused on user-centric experiences, the tools he left developers were serviceable but mostly afterthoughts. It was up to coders to service tools, not the other way around. XCode is not widely admired as an IDE, Objective-C is a good language but has its warts, and in general Jobs himself didn't see the biggest challenge as technical or code-centric, his innovations were mainly a finely-tuned intuition for the difference between elegant and simplistic, combined with a will, attention to detail and leadership drive to make those intuitions reality. He simplified touch interfaces, and left coders mostly to their own challenges, and I think he was right on with those priorities. In that, he totally "shared my attitude".

I do have an open mind, or I wouldn't still be coding and pushing myself to learn decades after scribbling out my first lines of BASIC on a TRS-80. But I also have enough experience with many, many codebases and have spent years learning techniques for simplifying and expressing complex domain problems. And the class of visual representation of those domains, of which NoFlo is just one more iteration, has very limited utility in that regard.

Is it possible that a better visual vocabulary for code will come along? Sure, why not? But it will be of a completely different class than what we've been presented with so far, and it certainly won't have been invented by IBM in the 70s.

How is this different than, say, Rational Rose or any of the other UML/WYSIWYG tools that have come down the pike over the years? Or, for instance, Rules Engines that in general no one uses because inevitably stakeholders stop trying to understand the "plain and simple" english-like syntax that have morphed into full-on semi-Turing Complete disasters that developers manage anyway?

Most code, when visualized in sequence or relational form, is generally incomprehensible even to developers until they've spent time understanding the intent and history of the domain. I can't convince most senior developers to learn to read and use the simplest of UML sequence diagrams. How are non-technical stakeholders supposed to be able to grok this?

Code is complex in the best of times, early in development. Legacy code that's actually used for business in the real world, even when visualized and distilled down to its simplest form, is generally a labyrinth of polymorphism, duplication, object/relational tension, algorithms, background jobs and asynchronous callback madness.

We've seen this kind of thing many, many times before. So often that by the early 2000s when some Golden Visual Environment For Code, the Holy Grail of "drag and drop", would emerge every couple of years or so, we used to roll our eyes and say, "here's another one." I wish I could dig up some of those links, but ALL of the language in this pitch is exactly the kind of thing we've been hearing for decades. And it never pans out.

The closest thing we have is UML. Look, I love UML, and I'm probably one of the last holdouts for it -- I read Martin Fowler's UML Distilled years ago and still use those techniques to this day. But I've never used it to generate code (a la Rational), or to fully diagram an entire system. Even with a human editor reducing the noise and focusing the diagrams on the core workflow, real world systems become extremely complex and very difficult to follow visually unless you have a long history with the system, an understanding of the patterns and architectural principles that went into designing it, and enough technical ability to grok things like inheritance, object/relational concerns, asynchronicity and the like. For these issues, the code isn't the challenge -- it's the concepts themselves, whether expressed visually or directly in code. Any system that grows to have significant business value will a) NOT be able to be maintained purely through visual environment and b) become so complex that the visual representation will be a mass of lines and boxes that, unless edited down and vastly simplified, will be too complex to read even for developers.

The Holy Grail of a visual, drag and drop environment that could create meaningful business value would have manifest years ago if it were possible or even desirable to do so. This latest attempt may end up having some limited utility for simple applications, but I'm beyond skeptical or pessimistic. This seems hopelessly naive to me.

I was about to post the exact same comment, with the above quote from OP in my clipboard.

In my experience, this claim is made by (many times really good, experienced, intelligent) coders who have a lot of previous experience in static typing and aren't comfortable -- either because of a lack of time and sheer LOC, or because of some mental block they've doubled-down on ("where's my 'extract method' menu option???") with the techniques and peculiar challenges of dynamic type refactorings.

I work on a very large application/system of applications in a dynamic environment, and I've never encountered refactoring or maintenance issues that I thought would have been any easier in my previous life, 10 yrs in static typing.

The other thing to keep in mind is that -- at least when comparing something like, for instance Rails to Java, there will be a lot less code, and this is a significant contribution to code management. That factor, plus just experience and acclimation to the techniques for dynamic-type editing/replacing/finding/greping and so on, plus solid TDD practices -- maintenance has never been an issue for me, and I've had a decent amount of time in large codebases in both dynamic and static environments.