Alan Kleymeyer

HTML 4 reference

HTML Tutorials

Jeff prefers Adam’s book on Windows Presentation Foundation, over Charles’.  Eric speaks out on behalf of Charles’ book.  Finally, Charles explains why he organized his book the way he did.

Let me just say that in an interview I had recently, Deep Understanding of .NET/C# was what the interviewer was looking for.

James Shore, an Agile Programming proponent writes:

Understanding XP

Mock dialog: "In my last company, we didn’t have any structure at all. People just
did what they felt was right. That worked okay when we were starting
out, but after a few years we started having terrible problems with
quality. We were always under the gun to meet deadlines, and we were
constantly running into surprises that prevented us from releasing on
time. Here, although we’re still able to do what we think is right,
there’s enough structure for everyone to understand what’s going on and
make constant progress."

Self-Documenting Code

Simplicity is in the eye of the beholder.  It doesn’t matter much if you
think the design is simple; if the rest of your team can’t understand
it, or if future maintainers of your software find it too complicated,
then it is.

Jeff states In his post Respecting Abstractions, that abstraction is good and you don’t always have to know how things work under the covers.

While no abstraction is perfect– you may need to dip your toes into
layers below the Framework from time to time– arguing that you must
have detailed knowledge of the layer under the abstraction to be
competent is counterproductive. While I don’t deny that knowledge of
the layers is critical for troubleshooting, we should respect the abstractions and spend most of our efforts fixing the leaks instead of bypassing

Eric writes about the .NET Abstraction Pile

This is what programmers do.  We build piles of abstractions.  We

design our own abstractions and then pile them up on top of layers we got from

somebody else.  Abstractions can be great.  We use them because they

save us a lot of time.  But abstractions can also cause lots of

problems.

Both posts refer to Joel’s essay "The Law of Leaky Abstractions".

One reason the law of leaky abstractions is problematic is that it
means that abstractions do not really simplify our lives as much as
they were meant to.

Jeff writes:

I’m not against dependencies. Everything software developers do is one giant string of dependencies. I’m a pragmatist. Strive to make your dependency stack as small as you possibly can.

If you take dependency avoidance too far you might get the Lava Flow anti-pattern:

As we delved into it, we interviewed many of the developers concerning
certain components of the massive pages of code printed out for us.
Over and over again we got the same answer, "I don’t know what that
class is for, it was written before I got here." We gradually realized
that between 30 and 50%
of the actual code comprising this complex system was not understood or
documented by any one currently working on it. Furthermore, as we
analyzed it, we learned that the questionable code really served no
purpose in the current system, rather it was mostly there from previous
attempts or approached by long-gone developers. The current staff,
while very bright, was loath to modify or delete code that they didn’t
write or didn’t know what it did for fear of breaking something and not
knowing why or how to fix it.

In his post "Non-Native UI Sucks" Jeff states:

When two applications with rough feature parity compete, the application with
the native UI will win. Every time. If you truly want to win the hearts and
minds of your users, you go to the metal and take full advantage of the native
UI.

I'm not even sure the native application has to be at parity with a competitor to win.

I also agree with Jeff's comments about the Java UI. UGGG-LYYYYYY. And SLOW.  Never met a Java app I didn't hate.