what i still don't know

Hey Ian, I really like the idea of Signal to Nois...

2010-12-22T11:34:47.258Z

Hey Ian,

I really like the idea of Signal to Noise ratio. I work on the Go team and have worked on Twist before that. In the past 4 years, I have not worked on a non-flaky functional test build.

Its not a horrendously bad pragmatic decision to follow this idea and live with the noise, as long as we are diligent about not calling bugs "noise" - which we inadvertently do sometimes as people stop checking functional test results on every checkin.

Apologies for not finishing sooner, been a very bu...

2010-12-15T16:19:48.275Z

Apologies for not finishing sooner, been a very busy year!

I am in the process of open sourcing an example windows forms app I've used in a couple of talks on Retlang, so look out for a post on that soon.

I'll also try and follow up on the final two themes soon!

Very nice post. Are you still planning to finish t...

2010-11-17T21:59:05.562Z

Very nice post. Are you still planning to finish the series up? I am working on implementing Retlang in a winforms application now.

It's actually AutomationProperties.AutomationI...

2010-03-22T17:12:36.855Z

It's actually AutomationProperties.AutomationId

not Name

Really liked your post. Can't wait to see the ...

2010-02-10T14:45:48.068Z

Really liked your post. Can't wait to see the next two. There is so little information and documentation about Retlang out there. This really helped!

I guess what I was trying to say is that, as with ...

2009-11-25T15:02:46.135Z

I guess what I was trying to say is that, as with most things in life, it depends on the situation.

When promoting code to production I feel having some kind of debugging mechanism ready to troubleshoot any issues caused by the production environment is key to rapid resolution.

Once in the production environment, and from then on, proper and useful logging is the way to go...

And as a previous post stated, logging (just like security) should be integrated into the code as it is being written, not treated as an afterthought. We use a library for logging that gets reused each time...in theory at least.

Someone said it more succinctly in 1979 "The...

2009-11-25T13:27:54.706Z

Someone said it more succinctly in 1979

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." -- Brian Kernighan

and followed it up with

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

you cannot debug most real production apps. the p...

2009-11-25T01:39:38.538Z

you cannot debug most real production apps. the performance hit is way to much.

i think he is suggesting that requiring that the logs be read will require them to design the log output just as they would any other part of the app. this is real functionality that has a real role/user that requires it.

how about a user story:

In order to be able quickly investigate and resolve user issues
As a customer support specialists
I need a log that will indicate what was happening, when it occurred and where exceptions occurred.

maybe you need this for every feature you are adding.

We built quite elaborate logging system for our ga...

2009-11-24T22:18:38.808Z

We built quite elaborate logging system for our game libraries.

It has really started to pay off and my usage of debugger has dramatically decreased. With debug traces, we can see the context of the problem, which is critical for reasoning about the execution in complex problem cases.

Building a good logging/tracing system is not a trivial task. There are a lot of aspects and design issues you need to consider: flexible tracing syntax, conditional tracing & conditional compilation of tracing for performance reasons, pretty printing, callstacks, robustly sending traces to server, etc. Different projects have different tracing needs, but I still find it odd that there isn't more quality open source qtracing libraries in common usage.

Banning the debugger is like cutting your legs off...

2009-11-24T20:27:52.197Z

Banning the debugger is like cutting your legs off. Doing so just before going live is even worse, because your developers are, at this point, used to their debugger; if you have to force them to use logfiles, you're probably without an efficient debugging method just before due day. I would recommend against it.

Next point: Too verbose a logfile is worse than useless, because it hides vital information in tons of tons of junk (if it really is in there). Developers tend to love stacktraces in logfiles, which is fine for debugging purposes, but useless for admins, how have to read logfiles of many different applications. As a rule of thumb, anything with a stacktrace attached is routed as bug back to development.

So I suggest to have an eye on your logfiles early in development. Make sure they are readable, not only by developers (because most logfiles are not read by developers), and completey free of junk. Ask one of your admin staff if he likes your logfiles and make sure he can find configuration problems himself. If he complains, listen. (Mind you, developers reading logfiles to find a wrong line in a configuration file is a brilliant way to throw away real money.)

Finally, log any exception which does not imply a configuration error with full stacktrace. No need to be shy here, a bug is a bug. But hey, that's what all people do, right?

Thanks for recommending this -- just what I needed...

2009-11-24T20:10:32.485Z

Thanks for recommending this -- just what I needed!

Good article. I sort out corporate computing messe...

2009-11-24T19:45:34.695Z

Good article. I sort out corporate computing messes of various scales. A debugger is cool to find out where something has been and whether it goes where you think it went. Sometimes -- often early in a gig -- it's the only way. But if you aren't developing on your logs, then you aren't developing maintainable software. And if you aren't developing maintainable software, then you've got a lot to learn.

I think if any two programmers used the same loggi...

2009-11-24T17:43:34.471Z

I think if any two programmers used the same logging format this would be great...and of course there are the devs who have a binary approach to logging and you either get nothing or, quite literally, a line of log for every line of code.

Another option of course it to provide the support function with a very 'thin' debugger app so they can view the code and locate the problem. Why this is good, in my opinion, is because variable/register values etc can be directly manipulated in the debugger to recreate the failure scenario. This depends on the abilities of the support staff I guess...

I just had a great Monday morning when I saw this ...

2009-04-27T04:20:00.000+01:00

I just had a great Monday morning when I saw this post... I remind people all the time how important tests are.. but sometimes I feel like some devs don't value tests as much as what they call "the production code".
One big problem is "design". We should design the tests as well... Refactor.. create abstractions, remove duplications whenever possible without removing the ability to read the test.
Perfect, congratulations Ian,
very good post..
I'll refer to it whenever I have one of these discussions when people argue that "tests will not go to production..."

An interesting analysis. Btw, that's six items, n...

2009-04-25T16:12:00.000+01:00

An interesting analysis. Btw, that's six items, not five!

I think the big objection I hear about writing tes...

2009-04-23T10:23:00.000+01:00

I think the big objection I hear about writing tests - particularly unit tests - is that as the code evolves then you have to re-write all the tests and so you are wasting time with all that test maintenance.

I say that if you need to change tests all the time then you probably aren't doing very good OO development. Classes that are well encapsulated with good interfaces that consume other interfaces via IoC will be flexible and composable and more than likely they will also be easily testable.

I also wrote this in a similar vein:

http://nomorehacks.wordpress.com/2008/11/05/when-is-a-unit-test-not-a-unit-test/

Very good post. When I first encountered TDD, this...

2009-04-23T09:58:00.000+01:00

Very good post. When I first encountered TDD, this was an epiphany for me. I began writing lots of tests, which helped tremendously - but I did not give as much thought to the organization of my tests suite as I did to the project itself, and over time the tests themselves started to become painful to work with, for pretty much the reasons you listed. The morale of the story for me is the same as for "regular" code: write it as if it's going to grow, and as if you will have to look at it later when you have forgotten everything about the project...

Really refreshing to read this. I agree with every...

2009-04-22T20:59:00.000+01:00

Really refreshing to read this. I agree with everything said in this post.Test Code should be treated as production code.

IMHO this is a slippery slope because

* When a development team is behind on schedule, I have seen devs start cutting corners in test code. That is when the Copy Paste syndrome which you highlight often comes into play. When I look at something like that these days, I thank my stars that atleast there is a test.

* If TDD'ing an area of code has become overly complex because of bad usage of mocks etc.. this often does not figure out in the Technical Debt list of a team.

* Test code refactoring also never gets considered when devs think of estimating a story, especially when dev team is too focused on getting the story done

In an ideal world, constant refactoring of test code along with production code should happen as a part of each story, and as we know the system better each day

Excellent advice. I've already referred people to ...

2009-04-22T20:14:00.000+01:00

Excellent advice. I've already referred people to it.

Because code "talks to the developer", and test code is code, then the intention of the test should be clear.

If we're using tests as executable specifications of system behaviour, then we should be very deliberate about how those specifications are expressed.

Names are very important, as is the abstraction of infrastructure (like SQL, HTML, even web testing tool API) as you describe.

The advice here will help high-performance teams have purposeful, easy-to-change tests that allow rapid turnaround of business requirements.

Good use of White. But for cross browser stuff or ...

2009-02-26T04:01:00.000Z

Good use of White. But for cross browser stuff or a simpler way of doing this, we have already done silverlight extension for Selenium. :)

Check this out http://code.google.com/p/silverlight-selenium/

Ian it was good to meet you last night. Please dr...

2009-02-05T09:56:00.000Z

Ian it was good to meet you last night. Please drop me a note about geek night and rabbitmq. Cheers, alexis

Thanks for making an interesting post, but I disag...

2009-01-11T03:29:00.000Z

Thanks for making an interesting post, but I disagree. Specifically, I disagree that not serializing your domain objects reduces the frequency of conflicts or makes conflict resolution easier. If user A fetches version 1 of an order and tries to change its shipping date and user B, who has also fetched version 1 of an order, also tries to change its shipping date then there is a conflict, whether they both sent and received "documents" to the server or serialized domain objects. Two "documents" that say the shipping date has changed are no different than 2 domain objects with different shipping dates (at least with respect to conflict resolution). Your solution to conflicts was
"...requests are processed one at a time, there is no complicated conflict resolution". If you've managed somehow to enforce that only one user is allowed to modify any given record at a time, then that is an unusual and convenient peculiarity of your system but has nothing to do whether data is exchanged with the client as serialized domain objects or "document" objects. Even with serialized domain objects you could still presumably enforce this arbitrary rule. Since you mention your concern for "large projects" I can't fathom how you're able to assume that requests are "handled one at a time". For all of the rest of us who are building scalable multi-user applications, we must deal with dozens, hundreds, or thousands of users potentially making simultaneous changes to the same pieces of data so we have to implement a strategy for concurrency, regardless of whether we send the client serialized domain objects or "document" objects or DTO's or anything else.

I don't see any relationship between the formatting of data exchanged and problems with concurrency or conflict resolution.

I also disagree that "document" objects or any other kinds of DTO make it easier to handle changes in requirements. With everything cleanly encapsulated within the same domain objects, fewer classes need to change when requirements change. Under your approach, if my business's concept of what an Order is changed, then I would have to change not only Order and maybe some UI, but also all of the "document" and other DTO objects. This sounds like less coherence, not more.

Thanks again for posting, though. It's a good discussion to have.

Totally agree with your points. I also think the ...

2008-08-11T17:02:00.000+01:00

Totally agree with your points. I also think the reason why unit tests gets deleted is because developers aren't perhaps aware that there's an option to mark each unit test as "ignored" within the test runner. That way, if a unit test is causing problems (i.e., needs to be refactored, the object under test changed drastically since the test was written, etc.), the test runner will simply ignore it. Then, have a process/review meeting where each ignored tests are challenged (i.e., are they still relevant? Why were they ignored? etc.)

totally agree. I have still to hear a good reason...

2008-08-08T23:45:00.000+01:00

totally agree. I have still to hear a good reason to delete a unit test, other than that the code that is being test has been delete as well!

Ian,

Intersting article, thank you.

...

2008-07-25T16:03:00.000+01:00

Ian,

Intersting article, thank you.

My hunch is that the multicore programming paradigm that'll prevail will be one which allows an evolutionary approach. Adopting a new language feels like a huge amount of "activation energy" to overcome.

I'd argue that what's needed is a sufficiently smooth path to multicore for all the legacy apps out there. Sure, folks will develop new apps, but for an organization that has a 5 million line C++ app, built over 10 years, it is a competitive imperative to move THAT to multicore, and soon.

For what it's worth, one resource we've recently created at Cilk Arts is an e-Book, "How to Survive the Multicore Software Revolution (Or At Least Survive the Hype)"

http://www.cilk.com/multicore-e-book/

Cheers,
ilya