The Pit of Success

RE: The Pit of Success

jlewicki — Fri, 03 Oct 2003 16:09:00 GMT

I definitely agree with your comments about API names; it always seemed unfortunate to me that there is a class called BindingManagerBase...I really would have preferred this to be just BindingManager. My rule of thumb is that I only use a 'Base' suffix in a class name only when clients arent using the type in a polymorphic fashion. So CollectionBase is fine, but BindingManagerBase is not... Of course if there had been an IBindingManager then this would not have been a problem...

RE: The Pit of Success

Shane King — Fri, 03 Oct 2003 17:37:00 GMT

Seems like a lot of great words that don't carry much meaning. Pretty much every language/API/framework developer would like to have things "just work", such that the obvious way to write code was the best. So I don't see a great deal of value of stating that, it should be obvious. Concrete ways of achieving this is what the big issue is. I'd love to see more and deeper usability research done on programming languages and frameworks, which might give us some data to base such work on. Otherwise, when you design something such that the "obvious" way is the right way, what you're really doing is designing it such that the right way is the way that's obvious to you. Which is a start, but not necessarily what's good for other people. It's funny how there seems to be an industry push towards usability guidelines backed up by studies and customer feedback when it comes to the UI in the end product. Yet the end product that us programmers use day in and day out is really designed on a "seems like the right thing to do to me" basis. Something that's largely been rejected due to poor results for the end users, yet we're made to suffer through it!

RE: The Pit of Success

Brad Abrams — Fri, 03 Oct 2003 19:44:00 GMT

Shane, your point is taken. In fact we have several fulltime API usability engineer that are constantly developing and running studies about what make good API design. There is nothing like sitting on the other side of the one-way class watching a developer struggle to use an API you thought you designed well. We are working hard to give that experience to designers of as many of the API sets as we can. But on a more leveraged scale are factoring much of that information into the Design Guidelines document and then into the design of our APIs. It seems there is clearly some value in getting more of the raw usability information out… I will see what I can do.

RE: The Pit of Success

Phil Syme — Sat, 04 Oct 2003 05:40:00 GMT

Although this is tangentially related, I wanted to add a "real life" experience. At my current day job, we're developing an extensive WinForms based desktop withing an n-tier .Net app. Our target deployment platforms is Win2k machines @500 Mhz w/256Mb ram (I would bet that this platform is the norm for large corporations such as the one I work for.) We recently started Ngen’ing on deploy, and the performance difference is incredible (for the better). From casual observation using perfmon, it appears that code is being JITed “all of the time” – possibly re-JITed or something else. The JITing is taking up most of the CPU most of the time on these low-end machines. Of course we will figure out the exact story of what and why this is so with enough time and effort, and correct the bad thing(s) we’ve done code-wise so that Ngen won’t make such a difference. My point is that I shouldn’t be in this situation. I’ve been a C/C++ guy for many years, and it’s my experience that you have to try very hard to not do the right thing to get bad performance from a C++ implementation. The same should hold true for .Net related activities. Please, throw me into the pit.

RE: The Pit of Success

KiwiBlue — Sat, 04 Oct 2003 13:51:00 GMT

Phil, I have to disagree with you on 'trying very hard to not to do the right thing' with respect to C++ implementation. Recently, I had to review a piece of C++ code which had been passing large vectors by value to various methods. Since the guy who wrote the code no longer works here, I don't know if he was just missing const &, or had no idea of how objects are passed by value in C++ (and how time-expensive memory allocation is).

RE: The Pit of Success

madhu — Mon, 06 Oct 2003 05:13:00 GMT

Brad, link to gotdotnet page you have in the post is not working can you repost the correct link

RE: The Pit of Success

Brad Abrams — Mon, 06 Oct 2003 07:46:00 GMT

Sorry about that -- fixed

RE: The Pit of Success

John Dhom — Mon, 06 Oct 2003 22:04:00 GMT

I like the metaphor... especially coming from a CLR guy ;) At first read (this blog and the headtrax perfwhacking session) I can see how you can do some of this with the CLR. It's a little less clear as you move up the food chain. I hope you find the following of interest... here's a half step up the food chain. Jitrz (java/.net) can do some interesting things beyond loading/compiling. Jitrz do late-bound, for lack of proper term, optimizations... things that take into account the run-time/access behavior... things that cannot be known at compile time (static). They establish an internal feedback loop regarding code and use. Now take the Headtrax perfwhacking report... much attention was paid to assemblies, disk access, etc.... even suggestions on optimizing deployment assemblies based on run-time specifics vs the logical model. Gah! [note: i understand why] I'd like the CLR (et. al.) to do for my assembly loading what the Jitrz do for late-bound optimization. In other words... figure it out and fix it. Ha! It has all the info on access patterns and probably load times. So in my perfect pit, headtrax developers too, the assembly performance (load) and access patterns would be analyzed and assemblies "regrouped" to improve performance. I can keep my [il]logical assembly groupings... the CLR optimizes it over time (based on it's current implementation and how users "use" the software)... and users get good performance by accident... I mean fall into the Pit of Success. /jhd

RE: The Pit of Success

Frank Hileman — Thu, 09 Oct 2003 16:00:00 GMT

The perf advantages of JIT compiling mentioned by John Dhom seem only to apply to server side applications. For client side apps, the user is so annoyed by the JIT delays that the JIT compiler cannot do much of any optimization. Consider that the new release of Office is not written in managed code. From the blog of Jason Zander: "We did some experiments early on in the Runtime as proof of concept for our managed C++ compiler which included recompiling Word as an IL image. It worked great! But it was slow. Office is a big application, and using the JIT for this case didn't put our best foot forward." MS cannot eat their own dogfood, but it is on our plates. The JIT compiler simply does not make sense for client side apps. Nor does it make sense for tiny devices such as the PocketPC. I can understand how small bits of code downloaded from the internet need JIT compiling for security. But to compile every installed client app, every time it is run, and to throw away the results: such a wasteful process (by default) throws us into the pit of failure! Also loading the IL when only the native code and metadata is needed, in an ngened app, makes no sense. Why does MS release and recommend technology that is not good enough for its own applications?

RE: The Pit of Success

Anonymous MS Developer — Wed, 15 Oct 2003 05:05:00 GMT

I think you'll find that managed code is being used in many more places as time goes on, there is a ramp-up time and no one thinks that rewriting an application for the fun of it is the best solution. The CLR team is doing some amazing things to improve perf and working set dramatically. Even then, it's not appropriate for all cases. The truth is that some things will remain unmanaged for a long time. But it's also true that many of the new features you see in new Microsoft products will be managed code. Yukon, Longhorn, WinFS, Avalon, Indigo - these all revolve around managed code. It's incredible the amount of investment there is. Good suggestions for doing NGEN; but as the Headtrax example shows, NGEN doesn't always help, and sometimes can hurt. Your focus on 'big' client apps may be misplaced; if anything a nice model is developing where a smaller amount of code mixed in with declarative programming (ASP.Net) is the sweet spot of development. Often, users want components that fit into a larger experience, rather than an all-encompassing experience on its own. Not every application is Office or Photoshop. If the cost of loading the CLR is already paid by the host application, the marginal cost of JIT for a component isn't too bad.

RE: The Pit of Success

Frank Hileman — Sun, 26 Oct 2003 15:59:00 GMT

Thank you for the response, anonymous. I was not only focusing on big client apps. If you look at the perf and windows forms newsgroups you will see a common complaint: the old app, ported to .net, starts up too slow. Often the problem is the jit on the designer generated code. Another common problem is the number of and size of dlls loaded. Even small apps often start up slowly compared to older C++ versions. Is the solution profiling, possibly ngen, and reworking the app? This is the only solution currently, but it is contrary to the "pit of success" idea at the top of this page. I don't believe there must be a trade-off. We should be able to use managed code and not have to think about performance any more than with a C++ app -- that is, focus on algorithms and data structures, not jit compile time. If something is jit once, it should be saved, and reused next time. Or ngen should be the default for desktop apps. Managed code is a great thing, but if the perf problems are not addressed, for client apps it may gradually aquire a reputation similar to that of Java client side code: slow and fat. I think managed code has the potential to replace almost all application code. Not all OS code, or games, but almost everywhere C or C++ is used. A real focus on perfomance and the idea of the "pit of success", by MS, would take it in that direction.

The trick with params

Brad Abrams — Sat, 31 Jan 2004 10:18:00 GMT

re: More Discussion of SOA is like the Night Sky...

PatHelland's WebLog — Sat, 27 Mar 2004 00:04:00 GMT

Filestream and BufferedStream

Brad Abrams — Fri, 16 Apr 2004 05:51:00 GMT

DateTime woes and

Lance's Whiteboard — Thu, 27 May 2004 17:00:00 GMT

A reminder as we start detailed design and implementation...

Brad Abrams — Tue, 09 May 2006 06:26:43 GMT

My team is starting detailed design and implementation work over the next week or so and I know of few...

Serializing Objects as JavaScript using Atlas, JSON.NET and AjaxPro

ComputerZen.com - Scott Hanselman — Wed, 05 Jul 2006 08:01:25 GMT

Performance: You are only as good as your measurements

Brad Abrams — Sun, 06 Aug 2006 00:41:12 GMT

I recently had a fun time baking cookies with my three year old son.. He had a great time scooping out...

(转)Serializing Objects as JavaScript using Atlas, JSON.NET and AjaxPro

若有若雾 — Wed, 16 Aug 2006 09:18:42 GMT

转自 http://www.hanselman.com/blog/

(转)Serializing Objects as JavaScript using Atlas, JSON.NET and AjaxPro

若有若雾 — Wed, 16 Aug 2006 09:20:57 GMT

转自http://www.hanselman.com/blog/

Sasha Sydoruk » Blog Archive » Code Access Security - It is not easy…

Sasha Sydoruk » Blog Archive » Code Access Security - It is not easy… — Sat, 09 Sep 2006 10:58:00 GMT

PingBack from http://www.sashasydoruk.com/?p=30

Will My Software Project Fail?

Programming — Tue, 24 Jul 2007 10:16:57 GMT

Most software projects fail . But that doesn't mean yours has to. The first question you should ask

Falling Into The Pit of Success

Programming — Sat, 15 Sep 2007 18:07:20 GMT

Eric Lippert notes the perils of programming in C++ : I often think of C++ as my own personal Pit of

Falling Into The Pit of Success at aoortic! dot com

Falling Into The Pit of Success at aoortic! dot com — Mon, 17 Sep 2007 01:51:42 GMT

PingBack from http://aoortic.com/?p=10011

Falling Into The Pit of Success at aoortic! dot com

Falling Into The Pit of Success at aoortic! dot com — Mon, 17 Sep 2007 01:52:17 GMT

PingBack from http://aoortic.com/?p=10024

Falling Into The Pit of Success at aoortic! dot com

Falling Into The Pit of Success at aoortic! dot com — Mon, 17 Sep 2007 01:53:20 GMT

PingBack from http://aoortic.com/?p=10038

Software Architect’s Site » Blog Archive » Falling Into The Pit of Success

Software Architect’s Site » Blog Archive » Falling Into The Pit of Success — Tue, 18 Sep 2007 14:12:54 GMT

PingBack from http://projects.akela.ro/portal/architectsblog/?p=104

GloryFish.org » Blog Archive » A Broken Billboard

GloryFish.org » Blog Archive » A Broken Billboard — Thu, 20 Sep 2007 22:11:14 GMT

PingBack from http://gloryfish.org/a-broken-billboard/

Wes Maldonado: Data Junkie » Notes from Alistair Cockburn’s Talk at the Seattle APLN Meeting

Tue, 16 Oct 2007 18:27:05 GMT

PingBack from http://www.brokenbuild.com/blog/2007/10/16/notes-from-alistair-cockburns-talk-at-the-seattle-apln-meeting/

Coder Peon » Flex API, le cas showHandCursor

Coder Peon » Flex API, le cas showHandCursor — Sun, 25 Nov 2007 21:00:27 GMT

PingBack from http://coderpeon.ovh.org/?p=41

Garr Reynolds Wisdom, Part I « Rowan Simpson

Garr Reynolds Wisdom, Part I « Rowan Simpson — Thu, 24 Jan 2008 10:39:10 GMT

PingBack from http://rowansimpson.com/2008/01/24/garr-reynolds-wisdom-part-i/

Notes on an inconsistent API

Bill Blogs in C# — Thu, 03 Apr 2008 05:45:47 GMT

When you design your API, make it easy to use and hard to misuse. Brad Abrams quotes Rico Mariani on

Notes on an inconsistent API

.Net World — Thu, 24 Apr 2008 23:20:31 GMT

When you design your API, make it easy to use and hard to misuse. Brad Abrams quotes Rico Mariani on

Scott Hanselman's Computer Zen - The Weekly Source Code 27 - Suck Less Libraries

Scott Hanselman's Computer Zen - The Weekly Source Code 27 - Suck Less Libraries — Wed, 21 May 2008 00:42:14 GMT

PingBack from http://www.hanselman.com/blog/TheWeeklySourceCode27SuckLessLibraries.aspx

The Weekly Source Code 27 - Suck Less Libraries

ASPInsiders — Wed, 21 May 2008 01:05:26 GMT

I've been getting more and more interested in how folks extend their applications using plugins and things.

The Weekly Source Code 27 - Suck Less Libraries | Developer Home

The Weekly Source Code 27 - Suck Less Libraries | Developer Home — Fri, 23 May 2008 01:21:15 GMT

PingBack from http://www.wowgoldip.com/2008/05/22/the-weekly-source-code-27-suck-less-libraries/

The Missing .NET #6: Version Tolerant Serialization | a geek trapped in a cool guy’s body

Mon, 07 Jul 2008 21:27:33 GMT

PingBack from http://www.ageektrapped.com/blog/the-missing-net-6-version-tolerant-serialization/

thinking in geek – ASP.NET == Usability disaster?

thinking in geek – ASP.NET == Usability disaster? — Mon, 29 Sep 2008 12:24:41 GMT

PingBack from http://joshrobb.com/blog/2007/09/29/aspnet-usability-disaster/

Rhino Mocks 3.5 RTM

Tim Barcz — Mon, 06 Oct 2008 04:20:01 GMT

Yesterday Oren announced the release of RhinoMocks 3.5 .  While the RC version has been out for

Rhino Mocks 3.5 RTM

Community Blogs — Wed, 08 Oct 2008 09:17:18 GMT

Yesterday Oren announced the release of RhinoMocks 3.5 .  While the RC version has been out for

journal.stuffwithstuff.com » Blog Archive » “Constrained Compound” Design Pattern

Mon, 24 Nov 2008 05:25:18 GMT

PingBack from http://journal.stuffwithstuff.com/2008/11/23/constrained-compound-design-pattern/

Enabling success with opinionated architecture

Jimmy Bogard — Mon, 12 Jan 2009 00:18:00 GMT

One of my pet peeve questions I often see on various tech mailing lists is “How can I prevent situation

Trying to extend the Asp.Net MVC (T4) item templates to create multiple files.

Eric Hexter — Thu, 05 Feb 2009 18:04:39 GMT

One of the features I was really excited about for the MVC RC was the template/Model based scaffolding

Build an Image HotSpot Designer in Silverlight

Community Blogs — Thu, 19 Mar 2009 23:25:14 GMT

Note: This article is submitted by Damon Payne for Silverlight: Write and Win contest .Thanks a lot,

Development and Integrity Management by Eli Lopian » Managing the support

Development and Integrity Management by Eli Lopian » Managing the support — Tue, 05 May 2009 09:26:06 GMT

PingBack from http://www.elilopian.com/2009/04/27/managing-the-support/

Brad Abrams The Pit of Success | Indoor Grills

Brad Abrams The Pit of Success | Indoor Grills — Wed, 03 Jun 2009 09:16:33 GMT

PingBack from http://indoorgrillsrecipes.info/story.php?id=10504

Brad Abrams The Pit of Success | Green Tea Fat Burner

Brad Abrams The Pit of Success | Green Tea Fat Burner — Mon, 08 Jun 2009 05:29:37 GMT

PingBack from http://greenteafatburner.info/story.php?id=1227

Brad Abrams The Pit of Success | Toe Nail Fungus

Brad Abrams The Pit of Success | Toe Nail Fungus — Tue, 09 Jun 2009 09:19:25 GMT

PingBack from http://toenailfungusite.info/story.php?id=3365

Brad Abrams The Pit of Success | internet marketing tools

Brad Abrams The Pit of Success | internet marketing tools — Tue, 16 Jun 2009 07:24:44 GMT

PingBack from http://einternetmarketingtools.info/story.php?id=21746