PDA

View Full Version : Technical Blog #1



John
05-25-2012, 03:18 PM
Friday, May 25 2012

http://stoicstudio.com/images/blog/jeff_john_victor_200x150.jpg (http://stoicstudio.com/forum/album.php?albumid=2&attachmentid=11)
As predicted in the last update, Jeff Uriarte has gotten started on the team and is working hard on the tools for building out our scenes and landscapes in-game. We have been working out the technical details of making the scenes as seamless as possible whether it is depicting the traveling caravan, a battle, or a town. We have figured out a good way to make these all part of the same rendering system, and are now working toward that.

Victor is making good progress on the FMOD integration. We have FMOD up and running in the game on our Windows build. The initial prototype was done using Visual Studio (with which we are both very familiar). To support our multi-platform approach Victor hoisted the code into Eclipse CDT and configured everything to build properly there. We are using CDT in Eclipse Indigo (the newest) rather than in Flash Builder, because Flash Builder is still on Eclipse Helios (an older version).

We spent some time today talking about the soundbank loading strategy we would use, and Victor is very close to having sounds hooked up to our abilities. So very soon we should hear weapons clashing in-game. Once we get the basic functionality working, we will immediately create the Mac port of the FMOD integration.

I have been spending a large amount of time refactoring an old crufty library that formed the core of our original prototype. That library contained code representing half a dozen different systemic responsibilities. I laboriously teased it all apart, creating new dependency-clean libraries for animation, abilities, battle, pathfinding, and others. Of the various engineering sins I committed while working on the prototype, the one that came back to haunt me the worst was overuse of a generic sort of ‘context’ object that was passed to object constructors all over the code base. My context object was just a holder for various, and unfortunately unrelated, pieces of data and functionality like logging, localization, abilities, resource loading, and others. This was done in the name of convenience and to limit the number of individual objects that had to be passed around. However, this approach just leads to dependencies bleeding through into places where they are not intended. I’ve got that all cleaned up now, for the most part.

One of the things that really helps when refactoring is having plenty of unit tests to rely on. One of the most powerful programming techniques I have ever learned is that of test-first-development (also called test-driven-development). I could write an entire article about the benefits of that, but having unit tests in place while refactoring is one of my favorites.

I also got a gameserver up and running, after lots of different technology tests and evaluations. When I last spoke to you, I was planning on running an JAX-RS embedded webserver application directly on EC2. However, there turn out to be much easier ways to scale. I looked into using AWS Elastic Beanstalk, and got a gameserver running there. Elastic Beanstalk runs a Tomcat container for you, and you just install your Jersey web apps into that. However, I find that running apps inside a container to be a little clumsy from my point of view, and somewhat more cumbersome to develop, deploy, and debug.

So I went back to heroku, a service that I had experimented with last year. When I had used it before, it supported node.js, ruby, php, and other technologies, but not Java. Lucky for me, they now support Java. I created a new application there, built it out, and deployed it. It turned out to be way easier than using Elastic Beanstalk, and I can use an embedded webserver (using Jetty this time) and not rely on Tomcat. So far so good. I’m a little concerned about the more premium pricing on heroku, but we’ll have to investigate that some more. However, the great thing about web apps is that they are so standardized that you can run them just about anywhere, so if we need to switch cloud services providers, it shouldn’t be too painful.

We’ve also started discussing how to deal with game accounts. We want to integrate all the services that Stoic provides (blog, webpage, forum, and TBS) into a single user account. We are looking at various ways of linking the game user accounts with the form (vbulletin) user accounts right now.

It’s a real joy to be working in Java again. It’s a fully mature language with some of the world’s best development tools. Using Flash Builder to develop with as3 can be an annoyance, by comparison. as3 is pretty mature, but it doesn’t really compare to Java in terms of ease of use.

I could go on for pages about the deficiencies of FlashBuilder and as3, but here are a few of my favorites:

FlashBuilder

An embarrassing lack of refactoring tools
‘open declaration’ sometimes just doesn’t work for symbols in another library
cut-and-paste of code doesn’t carry any metadata of required imports, as it does when editing Java
‘Organize Imports’ doesn’t add necessary imports -- must be done one by one. it does remove unused imports, which is nice.
‘Organize Imports’ sometimes freaks out and removes all imports. :(
absurdly slow compiler


AS3

as3 does not support abstract methods, which leads to all sorts of contortions when trying to provide base implementation and an abstract interface in the same place
The scope of local as3 variables bleed outside of their proper scope. Even more annoying is that I _know_ as3 is technically capable of properly scoping, because local variables for the caught exception in a try/catch block are scoped properly.
as3 has no enums
as3 has no parameterized types (aside from the Vector class which is special case)


Things are going really well right now. The 3 of us have a good bit of momentum and are making visible progress. In addition to ongoing work on the things I mentioned, we have the following tasks on the immediate horizon: improved animation timing support, implementing a Town scene, integrating with Steam, and PVP matchmaking.

In other news, the Texas summer heat is unrelenting and gathering power daily. So much that our little old AC unit can’t keep up, especially now that we have 5 men in a room with 5 computers, 8 monitors, and a fridge. So we replaced our AC with one a bit larger. This one comes with daylight streaming in from around the gaping styrofoam hole through which it is installed.

http://stoicstudio.com/images/blog/stoic_ac_650x488.jpg (http://stoicstudio.com/forum/album.php?albumid=2&attachmentid=12)

Previous: Technical Blog #0 (http://stoicstudio.com/forum/showthread.php?94-Technical-Blog-0)
Next: Technical Blog #2 (http://stoicstudio.com/forum/showthread.php?149-Technical-Blog-2)

Mudfly
05-25-2012, 04:14 PM
Wow, I don't get much of this, but i am very happy that you share what's going on with the game!

You guys are all awesome!

edit - hmmm i’m trying to decipher the post it’s on the whiteboard on the last picture... hard to see what’s on them though :)

kad136
05-25-2012, 04:25 PM
Context objects. *tsk tsk*

Thanks for sharing!

Flickerdart
05-25-2012, 06:02 PM
*hiss* daylight! It burnssss us!

jaggers
05-25-2012, 06:09 PM
Haha, John, I know exactly what you mean... a global-in-all-but-name! Yeah, that antipattern tends to grow tentacles and strangle every method it touches. At some point you're coding around its structure...

hatim
05-25-2012, 06:48 PM
John:
Great post!

What is your take on FDT?

cgjockel
05-25-2012, 06:49 PM
As a student of game art I do find it very fun to talk to programmers, we're in the final days of a game project at here at campus where I daily have the chance to mingle with the programmers as we, the artists & the programmers - all 14 of us share one open plan office space.

It's fun to see some similarites, we too have and use two gigantic whiteboards which are usually full of to-dos and lots of profane drawings.

kettels
05-25-2012, 06:49 PM
Its good to see the thought process going into it. As this continues on will you go into depth on the decisions from a programming perspective?

belamoor
05-25-2012, 06:50 PM
Though maybe for slightly different reasons i join the AC3 frustration as i have exams on Flash in 5 days. :)

starchasr27
05-25-2012, 08:52 PM
Didn't quite get all the technical stuff, but I was wondering what is a "crufty library"?

Avantre
05-25-2012, 10:48 PM
Good lord, is that a tall GLASS bottle of coca-cola I see there? They haven't had those in my country for a couple of decades! So jealous right now....

Oh yeah, thanks for the tech insights again.

(Need to get some duct tape around that aircon, stat, too).

Aaron
05-25-2012, 11:34 PM
what is a "crufty library"?

It usually means a software library that has more functionality than you actually need. Typically caused by bits being constantly added to the library over a period of time without cleanup.

Rusdude
05-26-2012, 12:38 PM
Good lord, is that a tall GLASS bottle of coca-cola I see there? They haven't had those in my country for a couple of decades! So jealous right now....

Oh yeah, thanks for the tech insights again.

(Need to get some duct tape around that aircon, stat, too).

That glass bottle is Coke made in Mexico that a lot of people prefer since it's still made with real sugar instead of high-fructose corn syrup like American Coke (along with other soda). It's prett easy to find down here in Texas.

Where are you guys working from? I think here in Houston buildings have had central A/C since 1950s or earlier :)

Arnie
05-26-2012, 05:06 PM
We're working from a tiny shack and yes, we're also in Texas where this coke is easy to come by. This one was sold about 20 feet outside our office at a food truck that serves really tasty tacos.

Chaille
05-26-2012, 06:27 PM
John, what about cats in the attic? Are you going to write some Young Adult fiction about that adventure?

John
05-27-2012, 12:46 AM
edit - hmmm i’m trying to decipher the post it’s on the whiteboard on the last picture... hard to see what’s on them though :)

Lots of upcoming/in progress tasks. The left column says 'Backlog', and at the top are things like 'PVP', 'Combat Fixes', 'Friend PVP', 'Steam Integration'.

The right column says 'In Progress', and is divided into three rows. The top 3 items are 'Combat UI Prog', 'UI Implementation', and 'Match Making'

JW

John
05-27-2012, 12:48 AM
John, what about cats in the attic? Are you going to write some Young Adult fiction about that adventure?

There's a voice in my head singing an epic song about them... or is that voice coming from the attic? Jess brought the Kitten by on Friday, I wish I had taken a picture!

John
05-27-2012, 12:49 AM
John:
Great post!

What is your take on FDT?

I certainly like it well enough. I haven't used it for about a year, and at the time I found FlashBuilder to be more stable and easy to use. I haven't re-evaluated it lately. I know that even back then its refactoring tools were miles ahead of FlashBuilder. I don't know that I'm interested in switching right now though.

John
05-27-2012, 12:53 AM
Where are you guys working from? I think here in Houston buildings have had central A/C since 1950s or earlier :)

There are some interesting cleanup pics of the shack/studio here:

http://stoicstudio.com/wp/?p=91

and a few more here:

http://www.facebook.com/media/set/?set=a.373915015953590.98013.366715340006891&type=3

stelly
05-28-2012, 03:17 AM
nice post, its nice to see how you guys are developing the game :)

Stelly

Kimberly
05-28-2012, 03:12 PM
"Elastic Beanstalk runs a Tomcat container for you, and you just install your Jersey web apps into that."

It's like reading a decidedly foreign yet vaguely familiar language. :p Most of the details of this post were lost on me, but I got the gist of it; glad to hear you're making good progress.

About linking making a unified game account, will it be possible to have different user account names from in-game names? While they work fine on the forum, a name full of numbers and multiple instances of the letter X is a tad immersion-breaking.

judd
05-28-2012, 07:32 PM
How does one go from Flash to a multi-platform product distributed on Steam? Is Flash just a prototype tool, or are you moving into an intermediate language that is portable before you go big time across all the target platforms?

-J

John
05-28-2012, 10:19 PM
How does one go from Flash to a multi-platform product distributed on Steam? Is Flash just a prototype tool, or are you moving into an intermediate language that is portable before you go big time across all the target platforms?

-J

Great questions. The short answer is that Flash and its surrounding technologies are now a multi-platform portable programming environment.

The long answer:

Flash technology has changed quite a bit over the last few years. Also, true to form, Adobe has named the various parts of it in the most confusing and obscure way possible. Let me try to break it down according to my understanding of it.

Flash: An art tool for generating animations and compositions of images (usually animated). The name of the tool is Flash CS6.

ActionScript3 (as3): A programming language similar to JavaScript that compiles down to bytecode. as3 can be written and included in Flash via the Flash CS6 tool. as3 can also be written totally by itself, typically written and debugged in a tool called Flash Builder 4.6. The compiled bytecode runs in the:

Flash Runtime: A virtual machine for executing as3 bytecode and displaying Flash animations and images. The flash runtime is typically part of the Flash Plugin which runs in your web browsers. Apple famously gave Adobe a kick to the nuts by refusing to allow the Flash Plugin to run on iOS.

Flex: The name of the as3 SDK. It's also the name of an as3 widget library. Adobe uses both terms in totally different contexts for maximum confusion.

AIR: A way of compiling as3 bytecode into native platform-specific code. This allows you to create native executables from as3 on Windows, Mac OS, Android, and iOS. This is very new technology. Speaking of intermediate languages, the AIR compiler uses LLVM compilers to generate native code.

Adobe Native Extensions: A way of writing C++ or other native code and linking it with your AIR project. It allows you to call native code from as3. This is even newer technology (fall 2011).

We are using AIR to deploy to Windows, Mac OS, and iOS (and potentially Android). We are using ANE to link with 3rd party libraries like FMOD (for sound) and platform specific stuff like GameCenter friends on iOS, Steam friends, etc. We are using Flash Builder to write, test, and debug our as3 code. We are using Flash CS6 to create our GUIs and to rotoscope all of our awesome hand drawn animation. We aren't using the Flash Plugin because we rely on several AIR-only technologies, including Adobe Native Extensions, as well as some improved AIR-only networking features. We will use ScaleForm to port to PSN, XBLA, Linux, and maybe Vita.

Does this answer your questions?

To answer your next question, why Flash and not Unity? Because our game relies heavily on 2d hand drawn animation, at which Flash particularly excels.

JW

judd
05-29-2012, 07:18 AM
Does this answer your questions?

Totally does, thanks for the great info.

-J

judd
05-29-2012, 03:19 PM
Great questions. The short answer is that Flash and its surrounding technologies are now a multi-platform portable programming environment...

So when I install this, I am installing AIR, running AS3 bytecode, rendering and coordinating assets generated in the Flash "pipeline"?

Before it would have just been an FLA right? Will you be releasing this to browser based players later - or does a browser based game diminish it's "impact" (or whatever you might want to call it, maybe it's "perception of quality")?

Thanks again for responding, it's a rare opportunity to ask questions like these to guys actually making cool stuff.

-J

John
05-29-2012, 04:31 PM
So when I install this, I am installing AIR, running AS3 bytecode, rendering and coordinating assets generated in the Flash "pipeline"?


From the player's point of view, it is no different than any other game on your platform. You run an installer, and ultimately launch the game with "TheBannerSaga.exe" or something (on Windows). On Mac OS, it installs like any other Application. On iOS, it installs as an App from the Store. The AS3 bytecode is a sort of intermediate language that gets compiled down to native code by the AIR compiler.



Before it would have just been an FLA right? Will you be releasing this to browser based players later - or does a browser based game diminish it's "impact" (or whatever you might want to call it, maybe it's "perception of quality")?


FLA is the source file format. That is the format that artists work in. It is equivalent to a PSD when working on images in photoshop. It has layers, settings, and all that stuff.

Flash compiles to a SWF file for consumption by web browser plugins. This is what you typically see online. You can double-click a SWF file and if you have Flash Player installed, it will execute.

I think it would be great to run in a browser, but we are using some AIR features that preclude this. A browser plugin can only run as3 bytecode, not compiled native code. The networking capabilities of Flash in the browser plugin are also limited, and we are going beyond those. If Adobe updates the browser plugin in the future to be more full-featured, or allows AIR apps to run in a browser plugin, we could consider that.

Right now the only option for us to run in the browser is probably via Chrome as a Native Client App. I would love to do that, but first things first.

JW

Illessa
05-31-2012, 05:14 PM
Great to see these technical posts, makes for an interesting contrast with Double Fine's higher level equivilants. Pretty expected since you guys are so much further along than DF, but together they definitely satisfy my itch for broad design chat and nitty-gritty toolset details :D.

Agreed as to the awesomeness of test-driven development. Personally I often feel I don't have time to write tests, but I always come to regret that decision. ;)

It also does my heart good to hear your feelings on Java too. I do a lot of Java development and find myself defending it a lot. Sure it's not the sexiest language, but the maturity, relative strictness, extensive native libraries and wide choice of excellent tools (special shoutout to the aweomse JRebel plugin (http://zeroturnaround.com/jrebel/) for saving untold hours of my time), IDEs and so forth make it a great choice for just Getting Stuff Done as a team.

John
05-31-2012, 10:11 PM
Agreed as to the awesomeness of test-driven development. Personally I often feel I don't have time to write tests, but I always come to regret that decision. ;)

Yep I have found that test-driven has always SAVED me time in the end. ALWAYS :) My one problem with TDD is that I find myself getting out of that mode when I am prototyping and don't know exactly what the end result is going to look like, or what the API will be. If I have a chance afterwards, I can re-write the prototype from scratch in TDD fashion and end up with something really tight. Sometimes, however, the prototype becomes the final product...

I've never learned to effectively mix TDD and rapid prototyping.



It also does my heart good to hear your feelings on Java too. I do a lot of Java development and find myself defending it a lot. Sure it's not the sexiest language, but the maturity, relative strictness, extensive native libraries and wide choice of excellent tools (special shoutout to the aweomse JRebel plugin (http://zeroturnaround.com/jrebel/) for saving untold hours of my time), IDEs and so forth make it a great choice for just Getting Stuff Done as a team.

Yep it's mature and the tools are wonderful. It runs everywhere. It's flexible. We wrote all our tools on Star Wars in C# and I came to love that also... in fact as a set of language features and syntax I prefer it to Java now, even though it seemed to start life as a shameless Java clone :). Java has a much more broad reach for deployment though, and an absurdly rich ecosystem of server libraries and tools. As much as I enjoy C#, writing a server in it would be a little iffy.

judd
06-01-2012, 07:12 PM
When you guys talk TDD, are you thinking "pure", as in literally write a test, let it fail, write some code, run the test - lather, rinse, repeat? Or is it more like write some code, write some tests, write some code, write some tests?

If the former, would you mind talking about it a little? I have found it pretty hard to get devs to make that happen and have found it hard to implement in general.

Thanks.

John
06-02-2012, 10:46 AM
When you guys talk TDD, are you thinking "pure", as in literally write a test, let it fail, write some code, run the test - lather, rinse, repeat? Or is it more like write some code, write some tests, write some code, write some tests?

If the former, would you mind talking about it a little? I have found it pretty hard to get devs to make that happen and have found it hard to implement in general.

Thanks.

Yes, I am thinking test-first. The test precedes the code because it serves an important purpose. The test is a statement about how you intend for the code to function. The test is the first client of your new code's API. You design how you want the interface to your new code to look, then you write the test that exercises it, step by step. By doing it this way, it encourages (and requires) you to put some up front thought into how you want your new module to behave, and to design its API in the most elegant way possible.

Writing the test first forces your APIs to be testable. If you write the code first, you are more likely to pull in excessive dependencies and not use a sufficient level of abstraction. If your module is testable as a unit, it is necessarily free of external dependencies. Saying that code is testable is equivalent in many ways to saying that code is free of dependency entanglement.

Writing the test first enables you to start with the simplest part of your unit's API (construction, possibly), and then layer on the rest of the functionality. With each layer added, your test guarantees that the previous functionality remains functional. If something breaks, you _already_ have a controlled environment in which to test the failure. Your tests are most likely boiled down to the fewest possible variables required to exercise functionality. Each of your tests pivots with minimal motion around a different conceptual fragment of your code, slicing and dicing its logical elements into fully comprehensible bits with the grace of the scientific method.

Debugging something that breaks in a test is so much easier than something that breaks in the running program. It is so much easier I would quite comfortably apply hyperbole such as 'an order of magnitude easier'. The same thing applies to things that break earlier, as soon as a defect or error occurs. If the defect propagates silently through the program, as is common, only to manifest itself in some part of the code distant in time and space to its origination, then I would multiply the spirit of my previous hyperbole by itself and claim that such a manifestation is 'order(s) of magnitude more difficult'. And possibly data-corrupting.

Having your tests in place mean than when you add or change functionality in the future, your refactorings can be done in confidence, and quickly. If your refactoring breaks existing code, you know immediately. If programming without source control is the real-world equivalent to driving without a seatbelt, refactoring without unit tests is the equivalent to motorcycle racing without a helmet. I don't feel very comfortable when I'm doing it.

One of the best programming books I've read is called Working Effectively with Legacy Code. In it, the author defines Legacy Code as: code without tests. I feel that this is a fantastic characterization. Think about every time you've tried to refactor legacy code. How many of those times were frustrating and difficult? How many times did you have to just throw the whole refactor out and start over? How many times did the result go live only to crash and flail around with unexpected errors?

The very first step to successful refactoring requires that tests be in place. If you have no tests, you must write them yourself. However... writing tests for legacy code can be quite difficult. Code that was written without the guiding constraint of minimal dependencies can actually be impossible to test. The first step to writing tests for legacy code is to break the offending dependencies by refactoring. Wait... but I only just said that refactoring requires that the tests already be in place. UGH. This is why code-first, test-later doesn't work.

In practice, it is not easy to do everything test-first. Code with mostly graphical or auditory output (graphics and sound systems) is tricky. User interfaces can be difficult. Code that you're writing as a sort of rapid-iteration prototype, for which you don't yet know the final form, is difficult. I use test-first wherever I can, and try to expand my use of it into new areas.

Test-first is a skill like any other. It takes time and practice to get good at it. But even a novice can write test-first for a good portion of the code they write. The trickier bits that I mentioned above come over time and with experience. Along the way you stumble into things and change your technique. For instance, one of the mistakes made while writing tests in general is to make your tests super complicated and fragile. A sign of a bad test is a test that constantly breaks and requires maintenance, or a test that requires loading external data. A bad test makes your life difficult, and a good one decreases your difficulty.

It is unsurprising to most people that having a codebase instrumented by unit tests leads to more reliable software. However, my own experience, and that of others that do test-first, is that writing code test-first leads to faster development. The speed and confidence with which the software is put together is improved by testing first. This is surprising or unbelievable to the opponents of testing.

One of my most successful and expansive experiences with test-first was on Star Wars. I had worked on and been largely responsible for the animation system for several years. It had grown from nothing into a massive but functional beast. As is typical for game development, requirements constantly change and evolve, requiring organic growth and ad-hoc refactoring. About 1 year before game launch, it was time to add some major new features and optimizations. Myself and my team re-designed the animation system from the ground up, and then implemented the system step by step, completely test-first. I have never experienced such reliability and speed of development. We ended up with equal parts of animation code and test code, about 50k lines of each. Typing those extra lines of code sped us up, rather than slowed us down. This is surprising to some, but if typing speed is one's limiting factor in producing working software, then that experience is much different than mine.

lamaz
06-04-2012, 06:02 AM
That was the most informative thing I have ever read about programming. I'm not a programmer and only posses the most basic knowledge about programming and I understood everything, which was a nice change of pace.

dezco
06-06-2012, 12:11 PM
Friday, May 25 2012
FlashBuilder

An embarrassing lack of refactoring tools
‘open declaration’ sometimes just doesn’t work for symbols in another library
cut-and-paste of code doesn’t carry any metadata of required imports, as it does when editing Java
‘Organize Imports’ doesn’t add necessary imports -- must be done one by one. it does remove unused imports, which is nice.
‘Organize Imports’ sometimes freaks out and removes all imports. :(
absurdly slow compiler



My organization also works with Flash and ActionScript, and we started with and were greatly frustrated by Adobe Flash Builder. So much so that we researched alternatives and have settled on JetBrains IntelliJ IDEA. It's not perfect, but it has additional features including code refactoring, import organization, and generally better performance. And it's got a 30-day trial.

I don't work for JetBrains, nor do I have a stake in their product, but I thought I'd post this as we ran into the same issues with Flash Builder.

And I'm with the group in saying that as a software developer, I enjoy reading your technical posts on your tools and code design. Thanks!

LvsAs
03-01-2013, 08:39 PM
We will use ScaleForm to port to PSN, XBLA, Linux, and maybe Vita.


About PSVita, PlayStation Mobile can be good for you or you need a full sdk vita game? Your game can be awesome on Vita, OLed 5inch screen, physical contrôleur, cross plateforme...

Darkenmal
03-02-2013, 12:47 PM
About PSVita, PlayStation Mobile can be good for you or you need a full sdk vita game? Your game can be awesome on Vita, OLed 5inch screen, physical contrôleur, cross plateforme...

Speaking of the Vita, I think it would be a excellent choice. If you look around, lots of indie devs have had huge success with the Vita. A good example would be Retro City Rampage, where it was the most successful platform.

So if any of the team is reading this, please release it! Many people would play it.

John
03-02-2013, 01:31 PM
I love the idea of the game on Vita as well!

LvsAs
03-02-2013, 08:26 PM
I hope it will be realized.

I don't know if it can be useful: https://psm.playstation.net/portal/en/index.html # register

This SDK may be too limited ... And make a game with full Vita SDK can be better.

Aleonymous
08-24-2015, 08:33 AM
One of my most successful and expansive experiences with test-first was on Star Wars. I had worked on and been largely responsible for the animation system for several years. It had grown from nothing into a massive but functional beast. As is typical for game development, requirements constantly change and evolve, requiring organic growth and ad-hoc refactoring. About 1 year before game launch, it was time to add some major new features and optimizations. Myself and my team re-designed the animation system from the ground up, and then implemented the system step by step, completely test-first. I have never experienced such reliability and speed of development. We ended up with equal parts of animation code and test code, about 50k lines of each. Typing those extra lines of code sped us up, rather than slowed us down. This is surprising to some, but if typing speed is one's limiting factor in producing working software, then that experience is much different than mine.

Aye, applying that test-first technique in the case you described, where the majority of what was outside the "black box" was fixed, would probably work wonderfully well. Things get more complicated with test-first if the architecture itself is not set in stone, e.g. when you're not sure exactly what the new feature is supposed to do.

John
08-24-2015, 11:35 AM
Aye, applying that test-first technique in the case you described, where the majority of what was outside the "black box" was fixed, would probably work wonderfully well. Things get more complicated with test-first if the architecture itself is not set in stone, e.g. when you're not sure exactly what the new feature is supposed to do.

In some cases, yes. If sweeping changes in project direction occur, your tests may have to get thrown out. However, for many cases of feature evolution, the tests form the backbone to support your refactoring. Supporting safe refactoring is really one of the most powerful features of having tests in place.

Aleonymous
08-25-2015, 05:42 AM
I am not so much into software engineering, but I have laboratory experience in electrical, electronic, microwave and optical equipment where there's this fundamental principle when trying/testing/measuring something new: Every failed attempt is more often related to problems with the testing environment (e.g. the settings of your sources or your measurement instruments) than to the device-under-test. That's why before initiating any big measurement you first set-up and test all the equipment. I guess it's similar with large programming projects: you have to have the backbone set-up and possess a good understanding of the environment (i.e. of "what's outside the black box") before moving on to the details and the constituting parts.

EDIT -- Verify that all your tech-blog posts are daisy-chained together. I think there's no link for 5->6 (only for 5<-6).