I celebrated over the weekend with hotpot at my mother's
significant other's house. It was great...I love hotpot! But so damn
tired from my drive home from Connecticut the night before (I live in
Jersey, but currently working in CT).
As we were eating, my sister relayed an amusing story to me
regarding my Amazon.com reviews. Apparently, one of her friends had
come across my review for the Microsoft Natural Ergo 4000 keyboard
while searching for a new keyboard. As relayed to me by my sister,
this friend became quite excited and called/emailed/messaged my sister
and started asking if she had a brother in North Brunswick. Funny how
small the world is I guess.
Even more interesting, this morning, I got an email from someone who
had read my review on the same keyboard and wanted to know if my
opinion had changed since owning it. Of course, I replied to this woman and told her that the 4000 is a fabulous <<in that nasal, metrosexual tone>> keyboard.
I going to have to take a look at this Composite UI Application Block from Microsoft's patterns and practices group.
It actually looks very similar (at least from a 10k foot view) to the architecture/design implemented by Omar Al Zabir in a writeup over at CodeProject.
I admit, I've never been much of a WinForms guy, as development of Windows clients has never really interested me (partially because of what a pain in the ass it is to work with WinForms compared to WebForms (XHTML markup just makes more sense for UI layout and presentation, at least in my opinion)), but I think it's probably worth my time to take a good look.
Having been a consultant for the last few years, I've been in many organizations, seen many application architectures, and met many developers. What saddens me is that far too few developers/consultants in the Microsoft space are digging the Patterns & Practices group in Microsoft. To a large extent, I think this issue is directly tied to how "easy" Microsoft has made the .Net development process. Certainly, it's quite easy to learn .Net, especially with the visual designers and drag-and-drop controls, but to write an enterprise application involves quite a bit more than building some of the samples out of a book and calling it a day.
I've consistently found that companies will continue to roll their own data access layers simply out of ignorance. Ignorance of the Enterprise Library, which is designed to be pretty much plug and play in so far as providing some infrastructure to common application needs. The case for Enterprise Library is fairly straight forward, in my opinion, but I'm amazed that so few developers I've come across actually know what it is and how to properly utilize (or even at least offer some alternatives (I myself prefer log4net for logging, but it's generally tougher to get companies to use open source projects vs. Microsoft products)). But even aside from Enterprise Library, there are a number of great solutions to the common problem of data acccess, including NHibernate and EntitySpaces (formerly dOOdads). While certainly, uptake and acceptance of third party solutions should expectedly be low, there's no reason why developers are not utilizing Enterprise library, aside from ignorance, NBH (Not Built Here) syndrome, and arrogance ("I can do it better"). This isn't to say that there is never the case for rolling your own solution, but you better make damn sure that you can come up with a convincing argument other than the three just listed.
On a more fundamental level, while .Net is generally considered a far more productive framework to utilize, as compared to Java or unmanaged code, it is also a lazier lanaguage that requires the developer to know less about architecture and designing software solutions. Combined with Microsoft's history with classic ASP and VB6, you end up with a lot of ".Net developers" who continue to write VB6 style applications and only use classes to demarcate the boundaries for a function set. There is a tremendous lack of understanding of object oriented programming concepts in almost every single organization I've worked with (with the lone exception being Factiva, where two of the developers in my group were really top notch). Seriously, ask some developers what the C# keywords abstract, virtual, and interface mean and you are guaranteed to get either looks of bewilderment or some off the wall answers.
This frustrates me to no end; my mind simply cannot handle this type of development. I've always been fond of the saying: "Never wrestle with pigs. You both get dirty, and the pig likes it." I feel an obligation to myself and, more importantly, to an organization that's paying for my services, to introduce standard practices, design patterns, solutions, and libraries where appropriate. I think this has gotten me into trouble on more than one occassion, including my current situation. I mean, 12 months ago, the idea of unit tests (as in NUnit) were lost on me. I didn't really understand the value of writing these tests and how to properly utilize them. I still do not feel that I'm solid on the latter, but I've definitely come to appreciate the value of unit tests and using a test driven approach to implementing code. I simply cannot write un-tested code nowadays as I find it inefficient and unprofessional. And yet, clients neither understand nor appreciate what it means to take a test driven approach. Instead, this type of development is actually discouraged as the front-loaded work is typically very far from the UI (at the class library level), which means that the business people and managers don't feel progress. I mean, I can feel it in their eyes when they look at me and wonder what I've been doing and why I haven't hacked together that WinForm yet.
Seriously, is there something wrong with me? Am I just being snobbish about this? I like to think not, as I openly admit that I myself underestimated the value and power of a test driven approach just 12-14 months ago and I've since undertaken the task of adopting it as SOP. But the thing is, very few developers, at least that I've worked with, take the initiative to learn technologies and software engineering practices beyond learning the base .Net framework. Mind you, I'm not talking about small time consultants with small companies. I'm taking about $150+/hr consultants working for multi-billion dollar companies. But then again, a lot of these consultants are not really in consulting positions; more accurately, they are really staff supplements, which typically puts them into a weaker position in terms of affecting change (myself included; this is what I really hate about so called consulting gigs, no one really wants to consult you on anything, they just want you to sit your ass down and write some code....now).
Enough ranting I guess. Understand that I'm not trying to come across as elitist in any sense; I simply expect developers to remain active in learning their discipline. I expect architects and consultants to understand the technologies in the relevant solution space before sending the devlopers off to write the code. I simply expect people to be educated and open to ideas, especially people in a technical lead role. In any case, Enterprise Library for .Net 2.0 is upon us. I'm actually fairly excited to put it to use and see how the team has improved upon the existing library. It's worth checking out Tom Hollander's blog (Microsoft's product manager for Enterprise Library (Yes, it's a full time project within Microsoft staffed by real life Microsoft employees)) for some of the dirt on the new features and changes in Enterprise Library for .Net 2.0.
On a closing note, I'd just like to make an observation. It always amazes me when I see people's desks with stacks of books that were obviously never touched. It's as if some developers think that they can learn by osmosis...keep that C# book close enough, and some of that info might just magically seep into your brain. I only wish it were so easy.
Perhaps even that is too weak a word.
Omar Al Zabir demonstrates an amazing breadth and depth of understanding of many technologies in addition to sound software engineering and design concepts.
He has a great writeup at CodeProject. That just blows me away in the elegance of the design and the way that he's able to have such a deep grasp of so many of the technologies that are relevant.
A higher order of abstraction. That's the answer.
What is the value in such a thing? With each level of abstraction that is added, you free up resources to work on higher order concepts. You free up the mind to work on the grand scheme. It wasn't until humams had sufficiently advanced agricultural technology that abstracted away the process of creating food, that the human race was able to go about it's business, doing bigger and better things.
It's the ultimate layer of abstraction. You go to the grocery store and pick up a head of lettuce or to 7-11 and pick up a bag of chips...you are almost oblivious to the enormity of the concept. Our ancestors even one hundred years ago would be amazed at the convenience that we have today.
Obviously, this abstraction could never have occurred without the right tools and technologies in place. Without the combustion engine, we'd still be tilling plots of land using horses and oxen. But if every person that wanted a combustion engine had to build his/her own, then that would also lead us nowhere.
Few of the managers in IT departments and business people ever think about building solutions in this light. They want ten people working to build engines on demand instead of investing in a small shop, equipped with high quality tools, to build only engines. People are mired in immediate needs and completing low order thoughts.
I need a tomato in three months. You better start growing one today.
There are of course, at several ways to deal with this problem. The simplest solution is to say "Well, if it pays the bills, I'll go dig a whole and plant that tomato seed". A more sophisticated approach would be to say "Well, I bet she'll want more tomatoes down the line, so I'll dig ten holes and grow ten plants". And even beyond that, you may start to get the big picture: "If I invest in machinery to dig these holes and plant the tomatos for me..."
The problem is in that initial investment. Few people have the foresight to see beyond it. Even if it'll take an extra month just to build that infrastructure, once it's in place, I can gaurantee you 100 tomatoes every month. I can even plant different tomatoes if you please, since most tomatoes have the same requirements. And even if you get sick of tomatoes and you want peppers now, with the machinery in place, I can switch to peppers if that suits your tastes.
Just one entry for today.
I was looking around for a free XPath expression tester online. Surprisingly, it took me at least 20 minutes to find a free one. Altova XMLSpy Home Edition, while free, does not include an XPath evaluator (it's an add-on in the professional edition).
However, I did find Dimitre Novatchev's excellent (though ugly as hell) XPath Visualizer.
Great tool (although the UI is ugly)! And you just can't argue with free
From time to time, as I'm working on projects, I invariably come across great sets of tools that make my life just a bit easier. My plan is to list the tools, test them out, and rate them somehow after I get some usage. I guess this is my way of sharing with the world
So for the inaugural entry, we have two tools and one library:
- FaceID Browser. When creating custom add-ins for Office applications, you can create a command bar button (CommandBarButton) and apply an existing Office icon using the FaceID property. This tool allows you to visually map the integer values to the icons. I've tested it to work with Office 2003.
- Xsd Generator with GAT. For some reason or another, I like the idea of working with XML schemas when building an object model; schemas seem much more natural to me than working with classes in code. In addition, you get nice XML serialization markup for free Matias Woloski has written a custom generator for .Net 2.0. I'm gonna give it a look-see. [Update:1] The binaries that are currently on the GDN website are not compatible with the RTM versions of VS2005. [Update:2] Holy crap. After several hours of fiddling, I finally got it to install. Damn, the December CTP of GAT extensions is still buggy as hell. For some reason or another, uninstalling the Xsd Generator after installing it would also remove all traces of the Microsoft.Practices.RecipeFramework dlls. WTF? So this would necessitate reinstalling the GAT extensions. On top of that, the December CTP changed the default namespace on the configuration file from http://schemas.microsoft.com/pag/ipg-core to http://schemas.microsoft.com/pag/gax-core took me at least a half an hour of digging to find this info. The other really stupid thing is that you can't change the config file after install without reinstalling...another big WTF; I mean, isn't that the whole point of having an XML config file? I also had to rebuild the references in two of the projects and add a missing reference to Microsoft.RecipeFramework.Common.Library. But in the end, it's worth the effort! I dig the fact that it generates generic lists instead of typed collections (typed collections are soo last gen. :-D).
- Microsoft Updater Application Block. Looks useful for anyone currently building lots of application add-ins for any of the Office applications as it will allow you to keep clients up-to-date without having to redeploy with each update. There's an article over at TheServerSide.Net on usage and details.
That's it for now. Look for more installments in the future.
I think that in these last two weeks, I'm finally starting to figure out the answer to one of my least favorite interview questions: where do you see yourself in x years?
I think the problem, in my case, is that my technical skills always shoehorn me into a developer's role, by default. However, doing things like building Windows forms and web forms here and there doesn't satisfy me. It's not challenging to build point solutions here and there.
One thing that I like about being a consultant is that I get to see many different environments and I get a chance to see how many different companies operate from an IT perspective. When I engage a client, I always end up thinking "big thoughts". I inevitably share my "big thoughts" with others and (you'd think I would learn my lesson by now) always end up with the short end of the stick, one way or another. Thinking "big thoughts" as a consultant isn't always a good idea for a number of reasons (or more accurately, sharing such thoughts with the customer); it inevitably leads to strife between the established developers and architects. To begin with, the business of thinking "big thoughts" is typically held by an employee of the client or by a less technical, more senior "architect" (either consultant or employee).
The problem with the former is that you rarely encounter an employee in a non-software related industry that really keeps up with the technology that changes so rapidly around them. Often times, companies are slow to move to newer technologies. There are companies that only switched from ASP to .Net in the last year; they're 3 years late to the party. Not only that, working within one environment for so long to be trusted with the role of "architect" typically means that one becomes too engrained in the ways of thinking of the other developers within the organization so there is a resistance to trying something new; there is a resistance to improving upon designs limited by weaker frameworks of the past. Instead, the new development is inevitably shoehorned into the "traditional" way of thinking ("this is the way we've always done it" (incidentally, this is what Scott Bellware meant to address when he coined the term "Visual Babytalk" (It's not that I have anything against VB.Net, in fact, I have a workshop written VB.Net, it's just that the majority of the developers that think in VB are from an antiquated era of software development))). A developer that wrote the last system in ASP+VBScript is going to be a bad choice to design the new system which will be implemented in ASP.Net+C#. The radical paradigm shift in architecture isn't apparent to many and most implementations end up being little less than .Netified versions of the old ASP applications using the same principles that were used when writing ASP. Yuck.
The problem with the latter is that more senior architects are typically less technical or they've strayed from their technical roots. Without a deep understanding of the technologies that are evolving, there is no way that good software design can arise. It ultimately ends up in a design that mirrors last gen. thinking. Now I'm not saying that senior architects can't design good systems. It's rather that there are so few architects that remain technically rooted in the latest technologies and software design principles (of course this is not to say that there aren't fundamental, "old school" principles that still hold). A part of the problem is the business model where a management position is equated with higher salaries. So instead of equating a higher salary with a more technically sound and educated developer, companies like to promote and bring in new developers (employee or consultant) that already know the new technologies. And let's face it, people have lives. As you progress in life, you will have children, you will have a house to take care of, you will have multitudes of responsibilities that distract from your ability to focus on studying technology and design principles. It's an issue I fear I will have to encounter in the next 5 years (and I thank my wife for taking a big burden off of me by taking care of most of the day-to-day responsibilities like paying bills and that sort of trivial stuff).
Now don't miscontrue my words; I hardly think that I'm "The One" or anything like that. In fact, I openly admit that I still have much to learn. When I say "big thoughts", I simply mean to think beyond satisfying immediate needs. It's the difference between giving a man a fish and teaching a man to fish. It's the difference between putting a bigger, more powerful engine into a below average car in hopes of driving sales versus building a better factory and hiring more skilled workers which will yield higher quality. It's the difference between trading for a basketball player that averages 5 points per game more to try to win games versus rethinking the offensive and defensive schemes to improve the chances of winning (i.e. Dallas Mavericks). It's the difference between designing a processor with a higher clock speed versus designing a more powerful processor (Intel Pentium IV vs. Intel Pentium M/AMD). It's the difference between thinking 2 weeks into the future and thinking 2 months down the line.
So I think I know what to ask next time I go into a job interview: does your organization like to think big thoughts? I don't want to sit around writing reports or tweaking Windows forms. I want to write the framework to help the developers more rapidly write and deploy the reports. I don't want to sit around tweaking Windows forms every time a business person wants to change a layout. I want to write the framework to allow for an easy to reconfigure UI. I don't want to do trivial programming tasks. I want to build complex things. I don't want to work under a technical architect/lead developer who's less technically educated than I am (I make a distinction between technical architect and business architect/analyst) unless said individual is open to new ideas, new technologies, and new ways of thinking. I like to think "big thoughts".
My managers and the customers (business people) don't always like that. Managers think small thoughts. They're like children in the sense that they have short foresight. Part of that is that they're at the whim of the business people and in the eyes of the business people, if you're not contributing to the bottom line today, you might as well be gone tomorrow. They've been conditioned to operate in a mode where quantity is valued over quality, where getting it done now is more important than getting it done right. When you work like this, what you end up with is a pieces of code that are cobbled together, difficult to maintain, and costly to fix.
Unfortunately, very few managers that work outside of software related industries think big. I don't think that I've ever met a manager that I would say "thinks big", but I think I've come close by having managers that allowed me to think big by trusting me and allowing me to work the way I like to work.
I remember telling Brian, my current managing consultant, that I like to work on things that don't have value. More accurately, I like to work on things that don't have immediate value. The value of such things is never apparent in the short term, as in the short term, the paying customer wants to see progress. When building such things that have little immediate value, it's very difficult for the customer to understand that if a little more effort is put in upfront to solve the more complex problem, then it will be many times cheaper to solve the simple problems down the line. Writing a framework to create and distribute reports costs a lot of money upfront with little to show for it. But the benefits down the line far outweigh the immediate costs as report after report is written and deployed using the framework (and it's not like a business is going to ever stop writing reports).
It's unfortunate for me that I've never really worked in a software
development company as I think that's where I'd fit in the best. But
at the same time, I think if I did work for a software development company, I wouldn't be exposed to the complex business problems that people are trying to solve. But for sure, I now understand what I want to do in the next 3-5 years: I want to solve big, complex problems.
On a tangent, I think I've figured out why I have problems making small talk and chit chat. It's because I don't want to talk about anything other than software design, technologies, and the process of building software Seriously, that's really just about all that I'm ever really thinking about when I'm not watching basketball or doing something mindless.
I guess I'm just ranting now The problem is that I'm thinking big thoughts, but mired in a situation where I'm forced to work on small ideas. It's terribly frustrating, to say the least. I feel so un-energetic each day. :-S