Planet Tech Art
Last update: January 31, 2015 02:00 PM
January 30, 2015

Wow, it’s hard to imagine that my blog is 4 today!  Pretty...



Wow, it’s hard to imagine that my blog is 4 today!  Pretty exciting stuff, I wish i was contributing more, but you know, sometimes you post and sometimes you don’t.  There is plenty of old stuff to read anyways!  I’m gonna try to get back to it soon.  Cheers.

by at January 30, 2015 05:49 AM


Amaranth v1.0 is out!

Hi folks!

Last year was all about open source for me, I finally removed my Windows partition and went full Linux (btw, gotta love arch linux), also decided to develop and share my projects under open source licenses (check out my github profile) and have been contributing to open source projects in hopes of giving back to the community. This post is about the latter.

I just wanted to share that there's a new release of Amaranth: a productivity addon for Blender by Pablo Vazquez (a.k.a. venomgfx).

I had always wanted to dive a bit deeper into Blender and this project seemed the perfect excuse to do it, so I gave it a try and decided to contribute by doing a much needed refactoring of the code base.

That's it... if you're interested in Blender please visit Amaranth's website and give it a chance. I honestly think it's worth it :)

Cheers!

by Cesar Saez at January 30, 2015 03:00 AM


January 29, 2015

How do you estimate that which you’ve never done?

Have you heard about #noestimates? No? Well I’m sure you can guess what it is anyway. But reading the debates reminded me of a story.

While at Game Developer’s Conference a few years ago, I was arguing about estimation with a certain project manager, who, despite having no actual development experience, was in charge of development (Icelandic society is notoriously nepotistic).

“So, maybe no estimation works for your small projects, but when you have to do big projects, and you need to ask for budget, and coordinate many departments and offices, and you need to plan all this in advance, what do you do? How would you plan Incarna?”

Incarna was CCP’s expansion that introduced avatar/character-based “gameplay” into EVE Online. What shipped was the ability for your avatar to walk (not run!) around a room. It was massively over budget, behind schedule, and under delivered. A few months later, 20% of the company was laid off. There’s been no active development on Incarna since 2011, and World of Darkness- which continued to use Incarna’s core technology- was cancelled and the team laid off earlier this year. It was, quite simply, the biggest disaster I’ve seen or heard of my career.*

A character-based game is also something CCP had never done before. They are massively- MASSIVELY- more technologically complex than the “marbles in viscous fluid” EVE flight simulator. CCP did not have the in house experience, especially in Iceland, where most of the (very smart) engineering team had never worked on character based games.

So it was pretty hi-larious that a project manager was using Incarna as an example of why estimation is necessary. But cognitive dissonance is nothing new. Anyway, my response was:

“You don’t plan Incarna. You greenlight a month of development. At the end of a month, you see where things are. Do you keep going for another month? If you are happy with the spend and progress, keep going. If not, pull the plug. Once you can make a prediction at the start of a month, and it holds true for that month, and you do this two times in a row, maybe make a prediction for two months and see how it plays out.
You may pass a year this way. Well, a year isn’t a long time for developing a character-based MMO and game engine from scratch. But at the end of the year, you at least have some experience. But you keep going. If your velocity is consistently predictable, you estimate further out. Eventually, if you can get your velocity stable at the same time you’re growing and developing, you have a fighting chance.**
When your velocity isn’t stable, you reign things in and figure out. If you go through a year of missed month-long predictions, you need to change things drastically (or reboot entirely) if you hope to get something predictable.”

Nothing really insightful there of course- I’m just parroting what has worked me me and many, many others, from Lean-inspired methodologies (and this one in particular says traditional yearly budget cycles are responsible for many terrible business decisions).

A couple months ago I was asked if a significant new feature could get done by June. It would build on several months of foundation and other features. I responded that I was pretty confident that if we aim for June we would have it by September. My rationale, simply, was that previous similar projects shipped 3 or more months late, and I didn’t have enough experience with the team to give a more accurate estimate.

The best predictor of future behavior is past behavior. You need to create historical data before you can extrapolate and plan.

The historical data also needs to be “meaningful.” That is a much more nuanced topic, though.


* It should go without saying that disasters the scale of Incarna are 100% at the hands of management.

** On Star Wars: The Old Republic, management took an interesting strategy of driving velocity into the ground so that while it was terrible individually, it was at least stable. They could then increase the number of people resources and predict, pretty reliably, when it could ship. The game ended up costing about $200 million (I suspect much more, actually), but it wouldn’t have shipped otherwise.

by Rob Galanakis at January 29, 2015 03:01 PM


January 26, 2015

Change should be the ally of quality

In The Beauty of Testing, Steven Sinofsky writes:

…great testers understand one the cardinal rules of software engineering—- change is the enemy of quality.

This is not a cardinal rule. This is a outdated and obsolete mode of thinking. Change is how you discover great UX. Change is how you refactor and reduce technical debt. Change is how you incrementally improve both your product and code quality.

Maybe that’s too obvious, and clearly Sinofsky isn’t arguing for static software. More nuanced (and the rest of the piece provides that nuance) would be “change inevitably introduces bugs, and bugs reduce quality.”

This too I take issue with. Your codebase should be verifiably better after you fix a bug: you’ve found a shortcoming in your automated tests, so you add a test, and maybe refactor some stuff as well. Or, you’ve identified a bad experience, and can change it to be better in a controlled manner. A bug is an opportunity for improvement. Without bugs, it can be very difficult to improve.*

It can be difficult for anyone who hasn’t worked in a codebase with extensive testing to understand this. In most cases, fixing bugs is playing whack-a-mole. Whack-a-mole is unacceptable to me. Every change we make at Cozy is making the code clearer, simpler, better tested. It’s making the product smoother, faster, and more intuitive.

Change is necessary; it is up to you to determine if it is a friend or foe.


If you’re practicing disciplined development and automated testing and not creating many bugs, good job! This post isn’t for you :)

by Rob Galanakis at January 26, 2015 03:38 PM


Mapping a texture to world coordinates. Part 3.

Example 2: laser effect



------------------------------- Distorting UVs -------------------------------

To start with, quick digression for beginners: 

If you want to animate a texture, the setup is very similar. Instead of plugging your distortion texture directly into the output texture, you add it to your texture coordinates beforehand.

What does that mean? Adding a value to texture coordinates means you are shifting the pixels around. 1 is the width and height of your texture.

Take a horizontal line.
Add 0 to it, it stays in place.
Add 0.5 to it, it moves to the top edge.
Add 1 to it, it appears to have stayed in place but really, it's been all around and back to its original position.


In the next example, I use a gradient from black to a 0.5 grey:


Reminders:
- Don't forget that the distortion texture should be linear (= not Srgb) if you're after a mathematically correct result.(I first made the mistake here and wondered why the result wasn't as exected.)
- You don't have to use black and white textures; you can use two channels to shift the U and V independently. Just use a component mask because UV info requires 2 channels while the RGB of a map is 3.


So. This is what you get from plugging directly the distortion texture in the output texture:

This is what you get from adding the distortion texture to texture coordinates before plugging it in the output texture:
 (note that I've reduced the influence of the distortion)

And this the animated preview: 

I've been through this quite quickly since we've kinda covered it before and most of you probably know this in and out. Don't hesitate if you have questions.


------------------------------- End of the digression -------------------------------



Now to our example.
Months ago I starting talking about mapping a texture using the world space rather than the UV space.

Here's a second example.
Say you've got a moving object which projects a laser that reveals the smoke in the air. We want our laser material to fake the fact it is lighting some smoke.
Now that I think about it, it might sound a bit previous gen, what with lit particles in every engine nowadays. Still I'll stick to this example because there can be more than one use to a principle. (and because I already spent a few hours on this!)

Whichever way the object moves, the smoke should remain static. You do not want the smoke material to be mapped to the UVs of your geometry or sprite. It should be mapped to the world where it supposedly belongs.

The moving object in my example is actually… fictional. Yes, you have to imagine it, all I've done is the ‘laser’. Which is not much of a laser in the end. I didn’t want to spend too much time polishing something which is not going to be used anywhere so I essentially stuck to the showcase of what this post is about: mapping textures to world space coordinates. I’ll keep the frills and glamour for some other day. (maybe)

Now, what do we have here?
A normal map is used twice (normal 1 and normal 2 boxes), mapped to world coordinates with different scales and panning at different speeds. They are brought together to use as a noise that will distort the UVs of another texture.
Usually you would add the result to a texture coordinates node. Since we are mapping our textures to the world, we’re using the world position setup instead, but the idea is exactly the same.

That goes into two different textures that get added together (all of that to add a bit of complexity so the patterns don't repeat too obviously) and into our output texture at last.












Finally, there you go:
The object moves in space and through the smoke.

by mkalt0235 (noreply@blogger.com) at January 26, 2015 10:49 AM


Race to the bottom?

I'm notorious for issuing gloomy pronouncements at GDC and elsewhere about the long term decline in artist pay.  I often point out that my starting salary in 1995 was about what an 6-year veteran makes today.  Maybe I'm just trying to scare the fainthearted out of the business and drive prices back up.

Still, my complaints are nothing compared to what's been going in the VFX industry.  The latest victim is PDI, which will be laying off 500 people.  While games has had it's ups and downs the last few years, VFX has had a brutal time with lots of closures and disruptions.

In that connection I came across VFXSoldier , a site which has been fighting for more unionization in the VFX world.  While I'm deeply ambivalent about unionizing in CG -- I don't know if it's really possible, much less a good idea -- but it's certainly not something to dismiss without thinking about and it is hard to see how it could make life worse for the poor VFX folks.  It's a worthwhile read just to see how the other half lives. I'm curious to hear what others think.


by Steve Theodore (noreply@blogger.com) at January 26, 2015 08:04 AM


January 23, 2015

BEWARE: Maya 2015 EXT / 2014 Constraint Incompatibility

incompat

I like to live on the edge when it comes to new versions of Maya, but rarely does it cause a major issue for me. A wise man once said ‘the moment you stop respecting something is when it bites you in the ass’. Well consider me bitten.

Anytime a rig I created with 2015 is loaded in 2014 it is irreparably broken. Spewing tons of errors like this one:
// Error: file: C:/Users/chris.evans/Desktop/test.ma line 210: The orientConstraint ‘nurbsSphere1_orientConstraint1′ has no ‘w0′ attribute. //

Diffing two constrained spheres, I noticed that there’s a new flag called ‘DCB’ or Disconnect Behavior.  Batch delete that and it seems that 2015 rigs can work in 2014.

But as usual, be a better person than me and just don’t open a file with a version of Maya your animators aren’t on. :D

The post BEWARE: Maya 2015 EXT / 2014 Constraint Incompatibility appeared first on Stumbling Toward 'Awesomeness'.

by admin at January 23, 2015 09:57 PM


The Trust Fund

A recent discussion on TAO reminded me of this old GDMag column from 2010. Tech artists always have to fight to stay focused on the relationship at the heart of our business: no amount of technical wizardry matters if your artists aren't actually benefitting from what you do.

While much has changed in the last five years, a lot of this still seems like good advice (to me, anyway, but I'm biased).  I might add a couple of sentences about 'more unit tests' and 'continuous integration' and similar buzzwords but that's just fluff: taking care of your users is all that really counts.



Every cloud, says the old cliche, has a silver lining.  Nobody likes the angst and insecurity of our dubious economy.  Still, in these lean times, at least we're far less likely to be dragged away from useful work for chirpy HR seminars on workplace communications or, God helps us, to don blindfolds and lean backwards into the clammy arms of that W.O.W. fanatic from IT so we can "learn to trust our teammates."  Say what you like about the dire business climate, at least it tamps down the fluff industry.

Honestly, though, the gurus of the workplace have it right about one thing. Blindfolds aside, trust is a key part of any functioning workplace and it's particularly important for us. We make art in a collective medium where all of the disciplines are inextricably tied up together.  You can make a career as a rock singer with a mediocre backing band.  You can prosper as the best actor on lame sitcom.  Cranking out great models for a game that crashes on load, however, isn't going to earn you fame or fortune. Our work can easily be dragged down by a lame graphics engine or a busted pipeline (though, to be fair, we should add that a fun design or a snappy engine can also be torpedoed by inadequate artwork).



Put bluntly, there are no lone geniuses in game art. We depend on other people -- graphics engineers, tools coders, designers, and our fellow artists --- to do what we do.

These relationships are the foundation of our work lives. This doesn't mean that you have start every whiteboard session with a group hug.  In our world, trust is more than just a warm fuzzy feeling.  A healthy respect for your teammates - or the suspicion that they don't know what they're doing -- shapes how you work in very concrete, un-emotional ways.

Trust Busted


Consider the morning ritual that greets most working artists at the beginning of the day.  Theoretically we all saunter in, fire up the box, and do a get to pull down the latest tools and most recent build of the engine.  We grab a cup of coffee while the our system assimilates yesterday's changes and by the time we're finished with icanhascheezburger.com, (wow, that is extremely 2010! –ed) we're all caught up and ready for the day's labors.
 




That's the theory, but it's rarely the practice.  Far too many artists will do anything to avoid that daily get.  "I don't like the risk," says one, "you never know if it's going to work from one day to the next."  Another artist complains, "The tool I need broke last month so I rolled back to a working one and now I don't want to get again." There's the perennial favorite, "It takes too long, so I only do it once a month." And don't forget the oldest standby of them all: "I don't worry about that stuff, I'm just need my Max files."

Sound familiar? This all-too-common story is a tangible example of a breakdown in trust, and you don't need to a special edition of Oprah to see how it undermines the studio.  If the artists don't trust the tools team, they try to bypass the tools and find workarounds. But this goes both ways: just imagine the dark mutterings coming from the engineering department every time they have to hunt down a 'bug' that's really caused by out-of-date tools or hacky workarounds.  The artists think the engineers are lost in the clouds, the tools team think the artists are big babies.  Pretty soon things bog down in recriminations and buck-passing.

The damage from this kind of breakdown goes far beyond eye-rolling and sarcastic IM messages.  It's more than everyday inter-departmental wrangling, too. If you cope with tool and process problems by simply opting out, you aren't just irritating the  tools coders or TA's -- you're also leaving your fellow artists hanging.

It's perfectly understandable, of course.  As an artist you're stuck with the studio toolset -- it's not like you can take your business somewhere else if you don't like the your in-house material editor or custom map tool. With deadlines looming and creative problems to solve, it's hard to gin up much enthusiasm for bird-dogging an obscure problem with a wonky exporter plugin or tracking down the exact setting that adds 11,000 warning messages to your map imports. The temptation to find a quick workaround and move on is overwhelming.

But – and here's the important part ! – ducking out on the problem doesn't just bypass it.  It perpetuates it, for you and for everybody else.

When the culture in the art department deals with tools problems by simply ignoring them, it becomes impossible for the tools team or tech artists to build long-term solutions.  Nobody's going to fix a bug that never gets reported, and nobody's going to improve on a bad workflow if the artists don't lobby for a real improvement.  Grumbling to each other at lunch doesn't count -- unless someone actually makes it clear that there's an issue, things won't get better. _Never_ underestimate how little the other departments know about your problems.  The political hassles of scheduling and finding resources for a real fix may be a problem that has to be settled among leads — but its every line artist's responsibilty to make sure both the art leadership and the tools team know when things are broken.

The old chestnut about trusting is that it leaves you vulnerable.   Working artists can relate to that, because nothing makes you feel more vulnerable than having a critical part of your pipeline break down when you've a looming deadline and the producer is breathing down your neck.  Trusting can be scary -- hell, the entire output of the Lifetime Network is devoted to that theme — but as every learn-to-love-again melodrama teaches you need to take some risks if you want to grow... or to ship good games.

Trust Building Excersize


Fortunately, there are some concrete things you can do to strengthen the bond of trust between the content team and the folks who are supposed to help them make the game —  and none of them requires a sit-down with Dr. Phil.

Testing


The most important way tools teams can build trust is to manage their releases better. Nobody would dare release a 99 cent iPhone game into the wild without testing and QA support (really? have you been to the App Store lately? –ed.)  All too often, though, tools teams and tech artists roll out changes without doing the legwork needed to make sure the tools work as advertised.  When teams were smaller and development was less ponderous, tool writers learned to love fixing bugs and adding features with a simple checkin. It feels great to be able to drop in a one line fix into a script and tell your disgruntled customer "just get the latest version and you'll be able to work again."

In a big modern studio, though, that immediacy is an expensive luxury. When you're supporting 50 or 100 artists, the costs of catching bugs late mount up quickly.  This is particularly true for tools like Max and Maya plugins, which can leave bad data inside art files long after the original bug is fixed.  No fix is fast enough to pay for the cost of dozens of angry, idled artists.  Bugs will always happen, but an aggressive testing program (complete with real, live testers, whether they're QA folks or tech artists), will go a long way toward easing the pain. Testing will certainly slow the response time for feature requests and trivial fixes.  But the benefits in terms of quality and reliability - and therefore, trust between the tools team and the content team -- are more than enough to pay for the hassle.

Regularity


Ship dates matter, as we all know too well. A planned release schedule for tools enhances trust, because it helps hard-working artists brace for changes. Tools that just magically appear in the daily synch are often simply ignored -- if the new skeleton editor came out while you were polishing run cycles, there's a good chance you don't even know its there (Note to tools and teacart teams everywhere: nobody reads those emails!)  When tools change their behavior or appearance without warning, artists lose faith in the stability of their environment.  And of course, if an innocent synch introduces bugs along with UI changes, the trust level will plummet and the vicious cycle of avoidance will begin.

If, on the other hand, tools go out the door at well advertised times -- hopefully, coordinated with production to avoid stepping on sensitive deadlines! -- everyone can budget the time and energy needed to make sure that the new functionality is supported, new workflows are well understood, and any bugs that slip through test are squashed before they do too much damage.  Scheduled releases, accompanied by scheduled learning time, are a safer and less intimidating way to keep the artists and tools builders communicating.

Uniformity


Trust, as the cliche goes, is a two-way street.  If we want the tools to get better, we need to contribute something too.  The effort that goes into doing tools with adequate testing and support is hard to sustain if the production people subvert the new tools and insist on their right to opt out of changes.  Keeping an art team productive is a herculean labor.  There are a million sources of potential problems: out of date video drivers, conflicting versions of software, different OS versions — you name itg. When every artist has a completely private environment, with personally selected versions of tools and private workarounds, support is exponentially harder. Time that should go to fixing bugs in the current version of the tool will be wasted simply trying to figure out what's going on and why.

Surrendering control over your personal working environment is emotionally difficult for most artists. We're slavishly devoted to customizing our hotkeys, tweaking the layout of our custom toolbars, and enhancing our personal workflows with scripts and widgets we've downloaded from the net. We want the same level of personal control over our in-house tools.  Unfortunately, the line between what's personal and what has to be shared with others can be pretty blurry.  Out of date tools may be producing data that's subtly wrong without being obviously busted, dragging down game performance or leading to crashes. Tools that are made to work together may function poorly if they aren't updated in tandem.  And working a completely private environment means you can't give meaningful feedback to the tools folks to help them do their jobs better.  The tools guys can only support one good environment at a time; it should be the one you're working on.


The touchy feely stuff


As any Oprah devotee knows, communication is the key to building trust.  Unfortunately, tools providers and line artists don't always communicate as well as they ought to.  Technical types tend to understand the needs of computers better than they do the needs of artists. They're always tempted to  to build tools that make things easier for computers, rather than helping artists.  Artists, on the other hand, are frequently too shy to  bring their concerns to the attention of the tools team.

If you don't tell people clearly what is broken in your workflow, what's preventing you from iterating, or what kind of changes would make things better, you have no right to bitch about the tools you've got.  Both sides need to explain their needs clearly and both sides need to listen attentively. Tech artists, who by nature have a foot in both worlds, are invaluable for helping these discussions along, as are producers who can provide high level guidance on the distinction between must-have and wouldn't-it-be-nice features.

The bottom line is really very simple. Artists, tech artists and tools engineers all need to commit to making things better.  Good tools don't make for good games on their own — but lousy tools certainly make for lousy games. So, if you skip the meetings, don't report bugs, and try to roll your own toolset, you're making your own life and your teammates lives harder in the long run.

Trust me on that.





by Steve Theodore (noreply@blogger.com) at January 23, 2015 05:23 AM


January 22, 2015

Working with CAD files

Working with CAD files in 3ds Max is the single most annoying thing I had to deal with in the past 2 years.

You´re reading this, so you probably know the issues:
You get some obscure file formats (.stl, .stp. .jt) and try to import it.
And then you either have already tesselated meshes, or "body objects". If you have body objects, you are tryin to convert to editable poly or editable mesh and that is were it starts to get real messy:

Messed up smoothing groups, thousands of unweld vertices, a mesh way too dense to do any unwrapping etc.
So you are wondering, if there are simply some import options you missed, because there has got to be an easy solution for that problem.

At least, thats what I thought.
So I did some research...

The most common tips for a one-click solution I found were:

1. Use Rhino to export CAD Objects to poly objects. You can get a demo license that will let you export a couple of times, which might be enough for your project.
I tried it and in some cases the meshes looked better, but still far away from what I was used to from modelling my own stuff.

2. Use MoI for export.
I tried this aswell and again: Sometimes the results were better, but most of the times they were still too messy for my taste.

So I did some experimenting on my own and here is what I got so far:

1. If you don´t need to use the files in animation...

A) Get a file format from the client, that exports to body objects if possible. If you import the file and you already have a tesselated mesh, then you are short a couple of options you would have had, if you had body objects. I had good experiences with .jt files for example.

B) If you have large files, get he client to split it for you. I spent numerous hours trying to export files that were just too bug to handle. I have a fairly capable workstation and I found anything above 50 MB too big to handle.

C) Either leave the files as body objects, or (if the scene is too heavy), change to "coarse" in Body Object options, add Edit Mesh modifier on top and collapse. Edit mesh for some reasons gives a way cleaner look than edit poly modifier. You can use the incredibly useful scrip "modifier modifier zorb" to change settings on multiple objects at once, add modifiers, collapse etc.

D) For UVs I usually try to get away with simple box/planar/cylindrical mapping. and avoid unwrapping. Cou can get pretty complex stuff done using just that or only unwrapping small parts of the model and composite maps (Decals, for example).

2. If you have to deal with animations/ complex UV layouts...

Retopo!!
But, and this is the most important tip of all:

Only for objects you actually need to!!

Use any tools you are comfortable with (I mostly use the graphite modeling tools for retopo), in some cases you can use the base geometry (body objects set to coarse and collapsed to mesh) as a starting point. Use "quadrify" from graphite modelling tools or the "quadify mesh modifier" and clean up the rest, but with more complex shapes it´s often faster to just retopo or even remodel from scratch.

It´s annoying as hell (especially since Autodesk owns most of those products and should be able to use their expertise to get better results for exporting/importing...), but there just is no "one-click" solution, get over it...
I spent way to much time looking for one.
Just remember that you only need really clean meshes for some reasons (deformations, complex unwrapping) and can get away with "ugly" meshes for a lot of purposes!

by Samuel Enslin (noreply@blogger.com) at January 22, 2015 11:34 AM


Technical debt metaphors get it so wrong

In my previous post about technical debt, I explained how modern definitions of technical debt are harmful. Now I turn my attention to equally harmful metaphors.

Viktoras Makauskas made the following metaphor in a comment on my last post. This is a pretty perfect stand-in for metaphors I’ve read in other articles that harmfully define technical debt.

Imagine your car gets a strange rattle. You go to your mechanic and he says, “it’s your exhaust pipe holder, you need to replace it, but it’s gonna take a while to order a part and ship it, so just park your car here and come back in a week”. You say “no, I have this weekend trip planned, is there something we can do now?”. They say “yeah, we’ll put a strap on it meanwhile, just drive a little more careful and it should hold, but make sure to come back and do a proper fix”. Mechanic charges you now, and then a bit later.

This seems sensible on first read. But upon closer inspection, it’s quite clear the roles here are totally wrong*:

  • The mechanic is the programmer (the role of the “expert”). Well, a mechanic may or may not see your car ever again. They do not have a vested interest in your choice. A mechanic’s relationship to a car is totally different from a programmer’s relationship to code.
  • “You” are the “business” (the role of the “stakeholder”). The metaphor assumes that if you are irresponsible, it only impacts you (it’s your car, your money, your time). This is a problem. A programmer is impacted by business decisions in a way a mechanic is not impacted by whether you fix your car now or later.

This isn’t a simple language problem. It is a fundamental misunderstanding of roles that is naive to the way software development works. Programmers will be the primary sufferers of technical debt. Eventually the business will suffer with a slower pace of innovation and development and higher turnover. But well before that, programmers will be fixing (and refixing) obscure bugs, will bristle under management that tells them to go faster, will be working extra hours to try to improve things, and will eventually burn out. The business will only suffer once real damage has been done to a programming team, and many have given up.

This is why control of technical debt must be in the hands of programmers. Definitions or metaphors that urge otherwise are actively harmful.

Let me close by pointing out I’m just repeating what Ward Cunningham has already written about the original technical debt metaphor. The article ends with:

A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.
I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.

Thanks Ward.


* There are also a couple other problems with this metaphor. First, if “you” and the mechanic are the same person, and responsible for both business and implementation? In that case, there’s no need for a metaphor at all. Second, what happens if the exhaust fails? Do you become stranded? Does the car catch fire? What’s presented here is a false choice between a “correct” solution (replacement) or a “sloppy” solution (strapping it on). Why not rent a car? If there’s no responsible-but-relatively-cheap decision (there almost always is!), it’s still never acceptable to make an irresponsible decision.

by Rob Galanakis at January 22, 2015 05:12 AM