 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
There's really no short answer to that question. I've been in software development for 25 years and got
involved in .NET in some of the earliest days, the first bits outside of Microsoft and wrote the first book on
Visual Basic.NET co-authored with Rocky Lothka. And for a couple years, for 2000 and 2001 just spent time
writing and speaking and training on .NET and then moved back to where I spent most of my career which is
consulting on software development. I've been doing that since the mid 80s. The Professional VB.NET book from Wrox, which is one of the better selling VB.NET titles, will be out in
the third edition in a couple of weeks and I think that this is going to be the final edition before the next
generation, the Whidbey generation is released. This book has actually sold very, very well and we're really
happy to have the opportunity to incorporate some of the things that we've learned in the course of doing real
.NET applications in to it. The first edition of this book was written, actually before, .NET was even released. So, as you can
imagine, and even though it was technically correct and everything. Once you've learned how to use something,
you just got to understand which areas to emphasis, and which areas don't need much attention. So I think the
third edition continues to improve the quality of that book. I'm looking forward to it coming out. Well, I was really happy to be asked to be involved in that patterns & practices group. I wrote me first
book on architecture and definition and design and I find in the Visual Basic community, which is where I come
from, there really isn't much attention given to that as there should be. The Visual Basic mentality is that
you through some controls on a form and you make it do something that hopefully is close to what they want. And
then you go take it to the sponsor of the project and see "Is this what you want?" and if it is, great. If not,
then I'll tweak it until I get it the way you want it. That works okay for small systems, for small applications. But it breaks down rapidly as you move up the
complexity scale. Unfortunately a lot of VB developers don't move up the scale on their practices, as they move
up the scale on the applications that they work on. Microsoft didn't help for years. I think, throughout the 90s and even up to maybe 2 years ago,
Microsoft's general approach was, well, we got the [...] tools, there they are, let's spread them out on the
table. You figure out how to use them, you figure out what the best practices are in taking care of them. And I
actually remember a session by Bill Gates in 1998, summer of 98, in which he was berated for that. That was one
of the things that lead to me writing the book because the [...] of the commission of the book was there.
That I think was the turning point, that as you know, it takes a long time to get an organization that
big refocus, and Microsoft, finally, has begun to finally emphasis patterns & practices . I hope that's going to
save a lot of project unnecessary costs because it's really easy to waste huge amounts of money on these large
corporate projects. There was one example in Nashville, not in the .NET space, in the Java space, but I don't think it has
much to do--but the technology is really not what drove the failure, but there was a public pronouncement about
it, articles about it, so I can talk about it, there's nothing serious about it. The company wrote off 120
million dollars for a year project and I would very much expect, that if you got down to root causes, it had to
do with lack of appropriate design, architecture and practices in making that software project work. I hope we get the advantage, building on what the Java community did, because starting with the Gang of
Four book and some of the other books that came out of that space, I certainly learned a lot. It was not
difficult to take the principle of what they where trying to teach and translate them into a .NET context. I
didn't find it to be to difficult at all. A singleton is a singleton, it doesn't matter what language you're
implementing it in. So, I certainly have a lot of respect for the people who thought through the abstraction to put those
patterns into place. And they thought through some of the architectural issues revolving around how you manage
state, and some of the big ticket items for doing large systems. So, I'm happy that they are the ones that got
the errors in the back and I hope we benefit from that experience and don't make some of the same mistakes. And
I don't think that they made some of those mistakes because of the environment they were in; it was because
they were pioneers. I was one of the early people in the Visual Basic community and I look at some of the programs that I
wrote, in VB 1 and 2, and I just--they were so bad. I wrote the first really large program that I wrote, had
probably a screen full of global variables. Because I didn't know any better, I didn't know the practices to
avoid that kind of thing, I didn't know the evils. Now what you've created in "Jell-O" code because you touch
it here but it just jiggles all over the place, because everything is tied together. So, I've made mistakes, so
I'm completely respectful of the fact that they made mistakes too. I think there's going to be a lot of contention between those two groups in the indefinite future. The
communities are balanced pretty nicely in terms of numbers. The visibility of the C# community is higher
because they have the early adopters and they go to the conferences. If we look around at TechEd here, we asked
in a session at lunch time today, and the C# developers outnumbered Visual Basic probably 3 to 1. But in the
community at large, it's much closer to 50/50 and in many areas of the country VB developers predominate. So,
in [...] Tennessee, the .NET developers group [...] VB will be 3 to 1 over C# in that community. The two groups are balanced. A lot of VB people will be coming in and they will more naturally--the VB 6
people will be coming from previous generations--and they will more naturally adopt VB. Some of them will go to
C#. A lot of the contention now, is in my mind and artifact of the transitionary phase because, truthfully, the
biggest difference in the language right now, the biggest difference is from a practical perspective, is that
the salary surveys said that the C# guys made more. Because of that people believe they have invested interest in going to C#. And I've seen cases where
individuals in every development shop of any significant size, there is one or small group of people, of
developers, who are really driving the new stuff that the organization is doing. And those people perceive, and
I think, it's in there benefit to go to C#, that it's trendy, that they will make more money, that they will be
more highly regarded. It's almost like the equivalent 20 years ago, if you were in sales, you wore a suit, because if you
didn't wear a suit you weren't considered a serious salesman. And the C# developers mind I think that if they
don't use C#, they're not perceived by certain people in the industry to be serious developers. I think releasing the tension helps. Because it lets the other side understand the humanity of the side
they're not on. Last year at TechEd, when I began a session in the Software Legends day, I was one of the last
people to go and most of the people who had gone up, all the people up to me, had done there demonstrations in
C#. So, I began the session by saying, "Okay, I'm going to do my demos, contrary to everyone else today, in
the most popular programming language in the world." And then the C# guys buzz about that a little bit and I said, "And I'm doing some pretty advanced
stuff"--I was going to say standard providers, if you know what they are--"but you C# guys, don't worry you
won't be left behind, you can do this too." And then I went on to tell them that I know that C# are excited about this managed code thing and I
think they should be because we VB developers have been doing managed code since 1991 and understand how
important and how good it is. And, of course, the new VB runtime, which everybody calls the CLR, is indeed much
better than the old VB runtime, and Microsoft is very nice to share it with the other languages. And that does help the C# guys understand that, even though I have a different perspective, really, we
all in this together. We ought to look at it as the language wars are over and we all won. And it's unfortunate
that some people can't look at it that way. There have been cases that I've been involved in in which C# developers, with the agenda of getting C#
as part of the organization have overtly lied about the capabilities of VB.NET, and that disturbs me. And there
are cases where I think VB.NET developers have been unreasonably reluctant to go to C#, perceiving it to be a
bigger jump than it is. So, I've seen both sides really not behave the way they should. There's no reason to be
at odds. The VB.NET community has one key thing to teach to the C# community and the Java community for that
matter. The VB community does better than any other developer community at balancing the business needs of a
particular system versus the technical needs because the VB developer is all about getting the job done.
Getting it done with these unreasonable time constraints, and getting it done within this unreasonable budget,
and let's be frank about it, cutting corners at times. There are many members of the C# and Java communities who are just absolutely aghast at the prospect of
putting out less-than-ideal software. I respect that attitude of not wanting to have defects in the software.
But we have to face the fact that in a world we live in there are plenty of companies around that if they had
waited to get the ideal software in place, wouldn't exist today. So VB developers are tuned in to that and they
are prepared to make compromises in ways that I thing C# and Java developers are not. So we certainly learn a lot from C# and Java developers about architecture and about good patterns and
good programming practices. I have found that my coding habits, even though I write in VB, the style is much
more like what a C# developer would do. You'll all know it if you look at my code and even though it's in
different syntax; stylistically it looks like C# code because I'm not using the old VB constructs. The VB 6 to VB.NET transition is a big one. And I'm not sure there's really been an appreciation for why
that is. The VB 6 community, because of that done philosophy has too great a tendency to just approach a
problem, I see an approach, and that approach usually involves running a lot of code. Then they turn the crank
and they grind out the code. And you just can't use VB.NET effectively that way. If you program in VB the way you did in VB 6, the syntactical things, they can get past that. I mean,
there's a nice link that every VB developer making the move should have: programming element support changes
summary, I think it's called, something like that. In which it's, here's the way you do it in VB 6, here's the
way you do it in VB.NET, here's the name space this thing is in, here's where you go for more stuff. That's no
big deal. But learning to use a framework that is really rich like the .NET framework is a big jump. The key value in the .NET environment is writing software with less code. And it's possible, and it's
quite feasible to write systems with one third the code that you would do in an equivalent VB 6. But if you
don't make the adjustment, and you don't learn the ways that that is accomplished, then the only advantage you
will get out of .NET is better deployment. You won't get any of the wondrous advantages because you won't be using the framework, you'll be
creating your own security code, or some such nonsense, or your own encryption code, and you'll be maintaining
that code instead of letting Microsoft maintain it. So that's the mental shift that VB developers have. There
are things that they don't have, that they don't have and continue now, that they will have that next time. But
you know what, for a couple months I didn't miss that [...] anymore. Because I'm just not writing as much code
and it's [...] I still occasionally "wish I could just change this" and I'm glad that it's coming back. But
it's not really something that changes you programming world. I have long thought since I first looked at .NET that there is A big gap. There's no equivalent in the
.NET world to what Access can do in the COM world. Given .NET is a big jump, it's made for people like me, that
just hated the fact that we just couldn't do inherited space frameworks, we couldn't run a [...] service, we
couldn't even alter visual controls in the language that used the visual controls the most. So VB.NET cured all
those things. It has made my own development experience so very much richer, but there's a big segment of VB
developers that need something that VB.NET does not offer. They work with data. All they do is shove data around and write business rules to work on it. And while
Whidbey's going to help in that regard. Whidbey's data story is quite a bit better than 1.0, 1.1. I still
believe that there is a lot of room to evolve that concept to the point where doing routine data oriented
development should be as easy as it is in Access with the extendibility of VB.NET because anybody that programs
in Access quickly gets frustrated with the fact that it's not written for programmers, it's written for users
and if you try to go behind the scenes and do things, it's just a mess. I haven't done anything as a consequence of Access for probably 10 years. But nevertheless I recognize
the power of that approach. Actually, I did. I did one quick thing for my son's softball team, I needed to
capture the names, addresses, phone numbers of like 20 people. And so, 5 minutes I've got the thing for them to
fill out on my laptop while they're waiting around and in Access that was the perfect tool for that. I can't
take the hour or two hours it would have taken me to write that for VB.NET. I think we're looking at baking data into the language at a level that is not there now. The missing
pieces, what I would call an expansive data dictionary. The idea that when you're talking about data today you
think of that as being a data type and that there may be a few minor things around that that you can store,
such as a default value in SQL server or whatever data store you have. But Access takes that part of it further so that you have a label that's associated with it. When you
design forms you know what label is suppose to go next to it. Access has a little bit of validation capability.
I'd like to see a data dictionary that would allow me to write a complete routine for that data
validation in the data dictionary and have it go to all the places that it needs to go automatically without me
having to write data objects to do that stuff. Because there's a big class of developers that would benefit
from that. So, this idea of having this very comprehensive data dictionary, we specify the stuff once--edit
masks, or whatever it is--the routine stuff, because that's infrastructure, you shouldn't have to do that.
Even little things. The fact that for example if you want to program a data application in .NET right
now, this is true in C# and VB.NET--dates, dates are a pain. Why are they a pain? Because the .NET data type
has no such thing as a null date meaning an unknown date. But in SQL server I can put a null in there. That
breaks data binding for example for dates; because data binding is always going to use one property. Now there are work arounds for that. I have a special control that wraps up a bunch of this stuff for
me, bit for a typical VB developer that's not at the level of being able to do that, that's a problem. He's got
very kludgy code. I cringe when I think of how many VB programmers out there for which the first date you can
have is hundreds of years in the past; the lowest date you can have. That date to the program means: I don't
know what the date is. Ted: That stands for Null. Right, that stands for Null. Ted: Somewhere around 0BC. Ya, stands for Null. So, I think there's tremendous improvement in the data space to be made because
that's the sweet spot in the industry, that's what the corporate developers spend all there time doing.
Should we express queries directly in the language? That's a very good question; I'd have to think
through that one a little bit. I've been happy with ADO.NET underneath. The disconnected model is very nice for
the distributed smart client stuff that I do. It's ideally designed for that, I mean, as a first out of the
gate, they're obviously nice things that can be done to it. Would it be good to put the query stuff in to the language? I'm not so sure that that would be good. I
think it would be better to have a very clever object model that you did it against instead of trying to
enhance the syntax of the language to do that, ala the X based languages. I don't know that that would be a
good idea. Well, people use the term "rich client" when, to me that's a very definite thing you should
differentiate from smart client. Smart client is a type of rich client . But rich client would apply all the
way back to the two tier client server world. And when we say "smart client" I don't know that there is
universal agreement on a definition, but just about everybody would say, well that means a certain level of
detachment of the client from the rest of the app. That it is capable of operating remotely and maybe with an
off line state which you don't normally expect a rich client to be able to do. So, I tend to use the word smart client, and sometimes, even though I consider it somewhat redundant, I
use the term distributed smart client to emphasis the fact that we're talking about systems that are
potentially distributed over the internet so that there are a server based piece, there's a web application,
but what it does, instead of sending out pages displayed in a browser, it's sending out containers of data. And
there's an application that is automatically deployed very easily to the client that accepts that container of
data, works on it, maybe offline, maybe not and when it's done, ships it back to be done. There are many, many
advantages to that approach and it's starting to become clear to a lot of corporate developers that that's a
better choice for a certain classes of application, browser based applications. That's hard to answer because first of all since I focus there and since to a certain degree I
evangelize there my own sample of people that I talk to is probably skewed, but of the projects I've worked on
in .NET, about 6 right now, all of them but one have been smart client based. And in at least 3 of those cases
there was discussion at the beginning about what it should be and some of the ones that were primarily smart
client still had web pieces. The thing I'm working on now is an automation of an entire production workflow cycle with a couple
hundred hands down operators. Now, in my mind that's a clear situation where you would want to choose a smart
client alternative because making those operators is absolutely productive as possible, it's critical. Not to
mention the fact that a lot of this workflow is the fax has come in to order things and we need to send these
faxes all over the place and they need to move around this image and do things--that's not the sort of thing
that a browser does very well, where you're overlaying things on top of the image or annotating it. Those
aren't really good browser possibilities plus the fact that we can control things down to the key stroke level
for data entry operators and validate the data much better. We finished a project recently where it's suited for a thousand or more operators and call centers
around the nation and they believe the productivity improvements are at least 10% and if you do the math that
results in many millions--several million dollars in productivity savings in a year. So there are some
situations in which I think it's clear cut and I thing people are going to realize that. Now, it's a slow thing because I remember in 1998, in 1999, when people would come to me and say, "We
want to do this new project, we want to do this new system and we're going to do this in--VB 6 was just
released--we're going to do it in Visual Basic 6." And I'm going, "No, you don't want to do that. You have got 500 users. You don't want to be taking care
of 500 desktops at a time." So we spent years educating the decision makers that, lots of desktops, do it browser based. And now,
we're having to re-educate because they didn't really get the idea I don't think that the primary reason to do
it was deployment, not because the browser stuff was cool, it was deployment. Ted: Well, maybe because browser stuff was cool at the time. It made my resume look good. Browser stuff had a cache about it. But it mostly had to do with the fact that you had the ability to
project your application to Afghanistan, I guess, if you can get an internet connection in Afghanistan, or
Outer Mongolia, or whatever. You've got the ability to get world wide reach, and there was simply no
competitive offering in the smart client world to do that. And in essence that was cool, but that still comes
back to the fact that you're talking about deployment. The reach of the app and how easy it is, and how cost
effective it is to get there. So, now that we have come around to the point where smart clients are not as cheap to deploy as browser
based, but the gap is very small then there are many situation where there are productivity improvements for,
let's say, if you're writing commercial software, the flash, the sizzle of the product, would put you in a
smart client world were four years ago browser based would have been your obvious choice. For some programmers it's a return to a lot of things that they new how to do. People who came up in the
Visual Baisc world doing client server development, at least some fraction of them have a good feel for true
GUI interface design. Web interface design is rather different then that and a lot of the skills for the
developers that have only lived in that world, they have some things to learn about interface design;
particularly about how they manage state and how you use state to your advantage on a smart client because
they're architectural principles dictated limited use of state because of the nature of the protocols they were
using. So, the idea of writing a stateful object to manage certain pieces of the user interface out there on a
client is something that they would never think to do. So they have some [...], but I think the first step
though is--I wrote an article called "Death of the Browser?"--browser's going to be around a long time, there
are good reasons to use the browser, it'll still be browsing [...] of my pages long after-- Ted: You heard it here first folks, Billy Hollis says, "Death of the Browser." Ya, it was really funny because I wrote that article and there was stuff all over the internet about,
"Microsoft says, 'Death of the Browser;" no, no ,no, it's just Billy Hollis, just this Joe. So, I wrote that article and it was interesting to read comics, because I just made a throw away line
about how you could do such amazing things in smart client that you couldn't do in a browser. And one of the
comments was "Well, you just don't understand what you can do in DHTML." Yes, I do. I absolutely do. But you still can't do it; can't do stuff you can do in a smart client.
You know, I'm really proud of being a part of that group, but it was a real shock, a complete shock to
be chosen for that. Software Legends were a group of people that were chosen in a process that Microsoft went
through, where they did some name recognition things, they look at book sales and things like that and they
were zeroing in on the people who had written the earliest .NET books. The ones who had really helped get the
message out for Microsoft, when, to be candid Microsoft's marketing department really didn't understand how to
get that message out there because .NET is really different, really new, and took them a little bit of a while
to get there heads around it. Those of us who have been through generations of development and understood the limitations of Visual
Basic for example and used it despite that, understood the limitations of ASP development, and used it despite
that, understood the limitations of COM and used it despite that, understood some of the good things that Java
did, while it had some other disadvantages at that time frame in performance. We understood that .NET was bringing together all of the best things of the industry and that it would
change the nature of software development. And we went out to articulate that message, and I was excited about
it. I hadn't got excited about a software development technology since VB 1. The other versions, they were just
versions. We've got objects, limited objects, in VB 4, that was nice. But some of us really did see it as a new world and we were the ones that were pointing people to that
new world and Microsoft wanted to help people in the general community understand that this group was doing
that. So, it was people like David Platt who wrote that very seminal book on introducing .NET, and people like
myself, with the first book that Wrox produced called, "Introducing .NET". The first chapter in that book and
several other chapters, plus the VB.NET preview book and other things. It's an interesting group because we're all, I think, easy going enough, and confident enough on our
abilities that the fact that cardboard cutouts, which should be a little intimidating--we're all pretty relaxed
about it. But we have a great time on stage, we do special events at TechEd. Give or take between the group is
really good. We can disagree without being mean about it. We have different perspectives that we bring to the
table and I think that--I'd be truly surprised by the high ratings of the Software Legends setting that TechEd
here and in Europe and the fact that the attendees seem to get a lot out of the fact that we don't prepare
anything, we're just up there talking about the issues of the day. But I guess we have a pretty broad
perspective, so, it's good for them to hear it. Jeff Richter is another Software Legend. And Alex Homer and Dave Sussman, the pioneers of ASP.NET stuff
for so many years for Wrox, and who am I leaving out? We sort of did them in a jumble so I'm not sure if I got
everybody in there or not. I mentioned David Platt I think earlier, as well as David Chappell. It's just been a
fabulous group to be involved with. David Platt and I shared a session at TechEd Europe and got some extremely high ratings. They sent me
back a very nice bottle of wine with that. But it is a little funny to see trading cards with your face on it
and the cardboard cutouts are petty funny to me because I'm the shortest of the Software Legends, I'm 5'8" and
you've got Chris Sells up there, and he's like 6'4", but when they made the cardboard cutouts, all they've got
is pictures and they made them all exactly 6 feet tall. So, when you line them up I'm as tall as Chris Sells in
the cardboard cutouts for the Software Legends. Okay, thanks |
