DevExpress Newsletter 14: Message from the CTO

04 November 2009

Reprinting my Message from the CTO from the fourteenth newsletter so that you may comment on my thoughts. Am I prescient or just nuts?

We're all beginners at some stage

In writing my chapters of Professional DevExpress ASP.NET Controls, I suddenly realized that there is really no way anymore to know everything about the OS, the platform, the run-times, or the language we use in our daily work. Sure, way back in the days of MS-DOS 6.22, you stood some chance of knowing most of it, but nowadays, especially as we're now learning more and more about Visual Studio 2010 and .NET 4, there's no possibility to make the time to learn it all, let alone say you know it.

Given that axiom, surely it makes sense that, if we are to use some fancy new tech in our app, we should spend some time in learning about said tech? For example, I hadn't actually written a web app that used AJAX before I wrote that part of the book. I could have just gone to our devs, thrown my weight around (it is considerable) and ordered them to make me an app or two and tell me how they did it, chop chop, but I decided to drop out and learn what it was all about through reading the documentation and writing some silly little throwaway apps.

Too often we don't do that, and too often we get irritated that something doesn't work the way we expect. Like everyone, I'd love for all software to be so intuitive that you don't have to crack open the help, but that utopia is very much in the future. Heck, even some iPhone apps aren't that intuitive.

The ability we should be cultivating within ourselves, then, is the ability to research, to experiment, and to learn about new software and not just take it on trust that we know innately how it works. This is the new job aptitude of the 21st century.

This was brought home to me by something that happened at home. My wife was using some medical X-ray viewer software that she'd never come across before. She wanted to print an X-ray from the database, but nothing she was doing worked. The X-ray was up on the screen, but it wouldn't print. I took a look at it, but it wasn't obvious at all. In fact, I had to read the help file to find out there was a little "selection" box in the lower right of the X-ray that, when clicked, selected the image for printing. OK, daft UI, but the point remains: if it's not obvious, read the documentation.

20 comment(s)
Joachim Meyer

> if it's not obvious, read the documentation

unfortunately much too often the documentation is either non existent, incomplete or too bad to waste your time on it. But even if the docs were perfect, who ready manuals anyway :-)

4 November, 2009
Brian Lowe

You suggest that we should know the details of what we're using, despite acknowledging the vast array of things we use and the impossibility of knowing it all.

We don't need to know how a TV works to watch our favourite show, or how an internal combustion engine works to be able to drive from A to B, although we *DO* need to know salient facts, such as how to change channels on the TV, and enough about car engines to make an informed choice between petrol and diesel, etc.

The point is we need to know interfaces and we need to have an appreciation of underlying technology - but the implementation and details should not concern us.

If my TV makes me press more than a couple of buttons and displays only red and black then I know it's faulty. I don't know what's wrong and shouldn't need to. I either get a different TV or get this one fixed by the manufacturer.

I want stuff with usable interfaces and reliable implementations. I don't want to have to climb a new learning curve every few months, and I don't want to have to understand the minutae of an implementation - if it doesn't "just work" then I look for something that does.

5 November, 2009
James Mayer

How about fixing the ASPxGridView Detail grids to make them enterprise level components with the respect that most businesses do not have unlimited bandwidth and require delete concurrency.

Master grid with 3 expanded rows  each detail row contains a page control each page control contains 5 pages each page contains a detail grid.

This master-grid hierarchy will perform 15 queries to the database on each and every postback of the page (put a button anywhere on the page and click it, the postback does not have to have any relationship to the grid) or any callback on the grid hierarchy.

Development deems it necessary to reload the contents of the grid each and every postback or callback.  Which completely invalidates delete concurrenty. The first act of a detail grid is to discard all data that the user was working with and requery the database.

Don't need oranges, don't need x-rays, just need professional enterprise level tools (by design).


5 November, 2009
T Gilbert

Very well said. I can admit I don't know how to do everything, but my ability to read and understand the directions trumps anything I know how to do today.

5 November, 2009

Unfortunately docs are sometimes bad, incomplete or useless. My sin is to dig through help and docs for too long before asking a real person for help.

Joachim - I do read manuals: my phone's, my digital camera's, my ikea's furniture...

5 November, 2009

Well said Mr. Bucknall

5 November, 2009
Douglas Clutter

I've been thinking along similar lines lately.  It has become almost impossible to flesh out the framework of an app without tossing about inside the components we'll use to assemble it.  Nothing turns on the proverbial light bulb better than trying to solve a specific problem with a specific toolkit.

5 November, 2009
Dave Friedel

"I suddenly realized that there is really no way anymore to know everything about the OS, the platform, the run-times, or the language we use in our daily work."

Isn't encapsulation wonderful...

one step closer to self awareness.

5 November, 2009
Dave Lindsley

I would agree that developers need to do more researching and experimenting; in my experience, most would prefer to do so, if their supervisors would support and defend such use of their time.

Or, to put it more succinctly:

One doesn't always have that luxury.  

5 November, 2009
Ruben Ruvalcaba Camba

Hi Julian,

I'm totally agree with you, when I began to programming world, I used to read the whole language reference book (they were less than 300 pages) and then you know all the language features, syntaxis and can figure out the application of mostly of them.

Nowadays that's just impossible and unworthy, I think the same you, the key for a programmer now, is the research and learning skills, in the past there weren't internet and often you have to find out the solutions by your self. Today you have to take advantage of the internet, and be cappable of differentiate the useful and unuseful information available.

5 November, 2009

MSDN documentation is so large that you can easily get lost and if you do find something relevant, it's hard to get your head around it all and be confident that you didn't miss something.

Toolkits, frameworks and APIs are also so big now that finding the appropriate 'tool' for the job is a huge task in itself.  My first thought when trying to get into both .NET and Java/J2EE was that it often took me more time to find the right API/code than it did for me to have written it from scratch off the top of my head.

All this contributes to a total slowdown in flow.

5 November, 2009
Rex Schmidt

Julian I have been programming systems since 1974 (I know!) and what you say in your final paragraph has always been the case. You can't just learn everything and expect that collected knowledge to solve all the problems you will encounter. Sometimes you will need to experiment and research to find ways to solve a particular problem.

The issue with that is that people often don't recognise the fact, so not enough time is allowed in project schedules to allow for it  and development plans are not flexible enough to allow for the changes in direction that may become obvious and necessary as you go along.

In any case its what makes this work fun and enjoyable. Remember -- when you stop learning you are probably dead; but may not have realised it yet.

5 November, 2009
Julian Bucknall (DevExpress)

James: Er, right. Since this is not a recognized support channel, I can't guarantee that our support team will read the comments to this post. Mehul took the liberty to pass your issue onto them and onto the devs concerned. You should be hearing back soon.

Cheers, Julian

5 November, 2009
stephen Ebichondo

Brian: I agree we don't need to know how an internal combustion engine works to be able to drive from A to B, but all the best race car drivers understand how it works!

5 November, 2009
Chris Merritt

Like many other respondents, I too have been programming for many years. The wisdom encpsulated in the concept of writing "silly throwaway apps" cannot be emphasized enough. I have always been astonished at how badly I initialy understood, say Help text, when I compare my second reading thereof to the first. Tinkering under the hood provides the context for understanding it better on the second reading. I have made it a habit to "guess" what the most complex parts to a general problem are and writing the solutions to those parts in thowaway apps using new technologies that I intuitively feel are "correct". Your observations hit the nail squarely on the head.

6 November, 2009
Donn Edwards

> if it's not obvious, read the documentation

Good old RTFM. I find that I can usually improve my apps considerably by WRITING the documentation. I'm often halfway through writing the explanation of how to do something when I realize there is a much simpler way to do it. Its counter-intuitive until you've done it, and then it takes the hassle out of writing the documentation.

Talking of documentation, a lot of the DevExpress documentation doesn't have examples, even though there are excellent examples available on your web site. You should consider linking to them somehow. I find the examples REALLY helpful and real time-savers.

6 November, 2009
Tim Whalen

The best athletes resort to the fundamentals again and again.  Not only does it make us better at what we do, but it makes us more empathetic as project managers - and that's always a good thing.

6 November, 2009

Reading the manual takes all the fun out of it...

6 November, 2009
Jason Short

I always tell new hires the same thing.  You don't have to know every .Net technology, but you do have to know how to use the documentation to find the information you need.  Too often people can't program unless they can find a complete working sample of what they need and can copy / paste the code.

The best thing most programmers could do for their career is learn how to inspect objects through Intellisense and read the MSDN docs.  Yes, auto gen docs are hard, you have to think in terms of the objects and classes, not what you want to do right now.  But this type of exploration is a part of programming.  There may not be a sample for what you want to do (usually not if it is hard).

Learn how to find the information in any doc system and you will be miles ahead of those that memorize how one object works or have a snippet library they always code from.

7 November, 2009
Mehul Harry (DevExpress)


The issue with several nested grids being heavy is well known but this is due to the nature of ASP.NET templates (detail row is a template container). We have to bind templates every time because data-binding in ASP.NET is weakly defined. It's not only data loading, it's also used to resolve databinding expressions (<%# ... %>).

Moreover, a control itself decides how to interpret "databinding" for itself.

However, I would not suggest nesting 15 grids. Enterprise level design usually contain domain model layers and not necessarily 15 nested grids.

Hope that helps.

11 November, 2009

Please login or register to post comments.