feedburner
Enter your email address:

Delivered by FeedBurner

CodeMash Wrap Up

I have had time now to get some sleep, and dial back into normal life, and decompress from CodeMash v1. Wow, what a ride!

There isn't much more I can say about CodeMash that other people haven't already said. Our sponsors were awesome. Both Pillar and MS stepped up at the last minute to make sure that drinks were available the whole time.

The QSI attendee party was a lot of fun, and I got to spend time catching up with people I don't get to see very often.

Organizing CodeMash was a huge effort, and it wouldn't have happened without everyone involved. Jason F, Jason G, Jim, Dianne, Josh, and Drew.

We have gotten a lot of great feedback on how it went, and we are already digesting that to make CodeMash v2 an even better experience! Our biggest issue right now is timing. Do we keep it in January? The problem we had this year is that the holidays really killed our planning and registration momentum. On the other hand, if we move it to November, our sponsors and attendees may not be able to make it to a second CodeMash after only 10 months. The board definitely has a lot to discuss.

It makes me so happy that the feedback was so positive from the conference. We have yet to fully process all of the session and event surveys, but I am looking forward to the final results.

I think my session on Networking for Nerds went well, considering I was exhausted, and had to chug two Cokes to even be able to stay awake in my own session.

 

Here are some blog links to check out:

We were the top search on Technorati!

http://www.flickr.com/photos/81259708@N00/364891112/

Speaker Chris Grant's thoughts:
http://cgrant.wordpress.com/2007/01/20/codemash/

Speaker Dave Donaldson's thoughts:
http://arcware.net/archive/2007/01/19/CodeMash-Rocked.aspx

Funny picture of Brian and Josh:
http://little.xmtp.net/blog/2007/01/20/i-made-it-back-alive-from-codemash/

This guy thought the food sucked??? He can't wait for CodeMash 2008 though:
http://www.alterzone.net/blog/2007/01/19/codemash-end-of-conference-thoughts/

CodeMash: A "rich, inspiring experience"
http://www.yepthatsme.com/2007/01/19/codemash-a-rich-inspiring-experience-more-to-come/

Another great post:

http://www.blueskyonmars.com/2007/01/18/great-job-codemash-organizers/

And this one really seems to summarize why we did this in the first place:

http://www.fallenrogue.com/articles/169-CodeMash-is-getting-its-code-on

http://becky-james.spaces.live.com/Blog/cns!74A46C0ED1C6586E!107.entry

And of course, Alexei's post of my head shaving experience:

http://feeds.feedburner.com/~r/AlexeyGovorin/~3/79452130/josh-and-brian-get-codemash-style.html

 

Make sure you check out the Google Group to see all of the great posts and feedback there.

We are working on updating the site to host the session content. This is a feature I wanted to have ready before CodeMash started, but I didn't have time. Hopefully Michael can bang it out, and we can get the content posted by the end of the week.

'Introduction to ASP.NET AJAX' at DevCares

Labels: ,

DevCares is a series of sessions aimed at the enterprise developer that is put on by Microsoft and sponsored by different training partners in each region. If you want to learn more, check out the site. The slides from the event should be located there shortly.

The DevCares events in Cincinnati, Ohio are sponsored by MaxTrain. MaxTrain is an excellent training partner. I have spoken there many times, and even taken a few classes. They have a new facility that is one of the nicest I have ever seen. If you are in the area, you should drop by and check it out.

The session went very well, and we got a lot of good questions, which I really like. We even got Mike (thanks!) from the audience up to be my code monkey. He did a great job, and showed how easy ASP.NET Ajax can be. We had over 65 people there! What a great turnout for a free event.

I spoke about ASP.NET Ajax, and how easy it is to use. We covered why UX is important, and the two main models of using Atlas ASP.NET Ajax.

The first, and easiest, is the Server centric model. This model allows you to continue to leverage the server side aspects of the ASP.NET model, which includes your skill sets, and server side processing. It is also the easiest way to upgrade your normal ASP.NET 2.0 site to AJAX. By using the update panel on your site, you can allow your client side elements to post back in an asynchronous manner. You can do all of this by not touching your code behind. You also don't have to significantly change the existing aspx markup. You have to add to it, but you don't have to change what you have. In earlier versions of Atlas, you would have to remove the normal ASP.NET text box, and replace it with the Atlas text box. The controls have been refactored, in a brilliant way, into extenders for the normal controls. So instead of ripping out the old controls, and putting new ones in (which requires rewiring the events, and a lot of testing), you can just add the appropriate extender to the existing control.

Even if you don't use the extenders, by wrapping some or all of the controls on your page with Update Panels, you can stop the full postbacks, and do an out of band (async) call back to the server. The update panels also reduce the amount of data going back and forth, by only sending the controls in the panel, and only receiving the changes markup that goes in the panel after the server processing.

The second model is the client centric model. We went into some samples, and covered how to consume different services from the client. The Atlas team has really listened to their customers, and have made significant changes on our behalf. Some of them are:

1. You can enable or disable the auto JavaScript proxy generation on .asmx services with an attribute on the service. This will avoid any performance hits on services that aren't going to be consumed by Ajax.

2. You must call back to the server to make a web service call. This is for security reasons, as well as performance reasons. Browsers tend to be very poor at processing XML data. So Ajax now relays the request to the Service Bridge on the server using JSON. The bridge translates it into the SOAP and sends the message on. This avoids the XML tax on the client.

3. Web Service references made on the client in Ajax are now a collection attached to the ScriptManager on the page, instead of just made in code. This makes for easier management of the services across components.

 

Anyway, check out the new RC of Ajax. RTM is supposed to be announced any time now. And check out DevCares.com to see if there is an event near you.

Discount on BizTalk Books

Labels:

Barnes and Noble has setup a special page for BizTalk books where Microsoft customers can get a 25% discount.

Just another reason I prefer B&N over Amazon.

http://btob.barnesandnoble.com/index.asp?r=1&btob=Y

3. If you aren't 10 minutes early, you're too late

Labels:

This is a very old rule of thumb. It was one of the first things I learned when I started my first job out of college.

You always want to plan on getting where you are going, whether it is a meeting two floors up, or across town, at LEAST ten minutes early. If there is risk in the travel, for example when driving downtown, and parking spaces is a constrained resource, you might want to pad the time even more. If you need to setup (for a demo, a projector, etc.) then make sure you are at least an hour early.

Something always happens to need that time. Such as:

  • Weird traffic
  • People who don't know how to move through a metal detector line at the airport
  • Don't know where you are going
  • "Annoying guy in office who never stops talking, regardless if you are on your way to a meeting"
  • Finding the conference room
  • Settling into the room (getting out laptop, etc.)

I knew a PM that would always walk around with his cell phone to his ear when he was busy trying to get to a meeting. This kept people from pulling him aside to chat about something while he was walking by. It was a great idea to use the cell phone as a decoy.

There is another aspect to why you should show up early, and it is more relevant for consultants. Don't ever let your client wait on you, you should always be waiting on them. I have always instinctively known this, but it really clicked when I heard a chef say that when he went into the kitchen to cook, he always started the oven and a pot of water on the stove, even if he didn't know what he was going to cook. He wanted the tools waiting for him, and not the other way around.

Making sure your client doesn't have to wait for you shows that you respect their time and attention. If you show up late, you are saying there are other priorities than them. While there might be other priorities in reality, the client you are with is the most important one at that time.

This extra time helps you settle into the room, meet and greet other people, and get ready to start the meeting ON TIME. The start time of a meeting is when the agenda starts, not when you should walk through the door.

I once showed up to a pitch for a project early. I didn't really expect to win the pitch, but it was a client that we were trying to win in a long term manner. Sometimes that means you need to swing at a bad pitch just to get noticed, hoping they know you later when they are ready for you.

I had showed up to this pitch with my materials and demos about an hour early. I was to demo right after another vendor. While I was sitting and waiting, the client came out and asked me to get started about 45 minutes early. The other vendor was late, hadn't called, so they were going to be skipped.

We won the deal.

Always plan to arrive early, so that you may be ready when you client is.

2. Always hold the door

Labels:

One of the three mystical PM's (a reference to rule 1) taught me this years ago telling me a story.

A person was entering an office building for an interview. On the way in, he paused, and held the door for someone. That someone went straight to the elevator and on with their day as usual. The person went to the receptionist and asked to meet with their contact for the interview. The candidate was asked to take a seat. A few minutes later, the same someone he held the door open for came down and started the interview. It turns out that holding the door open was a factor in the decision.

This is a corollary to the "Never burn bridges, no matter how much fun it might sound like" rule. Always be on your best manners. You never know when 'that person' might be someone you run into later.

Not a week or two after hearing the above story I ran into a chance to put it into action.

I was out of town on business, and was staying at a hotel for the week. This was in the North East, and there was a significant snow storm during the night. After breakfast, I went out to the parking lot to jump in the car and drive the half mile to the client site, which is such an American thing to do!

While outside, a woman (older, overweight, but dressed in a business casual way) was trying to get her car unstuck from some snow and ice in the hotel parking lot without getting messy. I was in some business formal clothing, but offered to help push the car out of the spot. After some grunt work, the car was free. In the sudden lurch, I slipped and jammed my chin on the car's bumped. The lady waived, and hurried off to where ever she needed to go.

I went back into the hotel to change my clothes, and the desk clerk freaked that I had blood all over my chin, and shirt. I went up, changed, played doctor, and proceeded on with my day. I also called my client to let them know I would be a little late (another rule coming up.)

When I finally got to the office, and started the day, it turns out that the first meeting (we were meeting different customers and client managers to gather input for the project) was with the women I helped in the parking lot.

The meeting went very well.

Rule 2: Always be on your best behavior, and mindful of your manners. You never know who that stranger might be.

Now Hiring!

Labels:

We have several open positions on my team (located in central Ohio). We are looking for passionate, thinking developers with good experience in C#, Smart Clients, and SOA. If you are interested please send me your contact information.

Also, we are adding a person to our Connected System Team. You have to love SOA/ESB, able to travel a bit, have good consulting skills, and experience (at least some) with BizTalk, XML, XSLT,  and .NET. Your fist six months to a year will be in a apprentice role because we find it very hard to find it easier to groom and train the right person. We do a lot of work with Microsoft, and it is a lot of fun! In the past year we have been building a lot of ESBs, but there is the fair amount of traditional integration work. Many projects are POC in nature.

You should already have a good sense of what we look for if you have read this blog recently.

Check out my profile for my email address.

1: A PM's job is not to manage the project

Labels:

Sure, a PM wants you to think that is their job, to manage the project. That is their title after all. And that is what they study, especially to get their PMP certification.

A lot of developers don't like PM's, and it is a shame. Probably because they have had bad experiences in the past. PM's are like any technology. They can be used for good or evil.

I am hear to say that while they do manage the budget, and timeline, and lots of other things, that is not their job. Any sound person can use MS Project (or other tools) to do this, and for most projects, do alright. (Don't think I am dismissing these activities, because they are critical as well.)

No, the most important job of a PM is to manage the client. What? Yes, manage the client. The client is the one resource on a project that requires the most care, and is the absolute most critical to the success of the project.

And part of this client management is to manage the expectations of the client. Both of the project process itself and of the project's final deliverables (completed system, or whatever).

It is easy to forget about why a client has hired you to do a project. Sometimes you don't really know what the true drivers for a project are (and you should really find out if you don't know.) You get lost in the details, and technical challenges, and you forget there is this person (or group of people) that have their own expectations for the project. The project team then becomes disconnected from the actual drivers and the client. And I have never seen a success once that has happened; seen plenty of train wrecks, never a success.

These expectations need to be managed. The best way is through communication, which is where a GOOD PM excels. The PM should constantly be finding out what the client's expectations are, and make sure that the project, is in line with them. Sometimes, (maybe more often than I want to admit), the expectations can be a little off kilter. This is where the fine art of expectation therapy comes in. There are only three PM's I know that have done this well, but many do ok at it.

When you find out that there is an issue with the client expectations (unrealistic for example, or they changed because, well, things change), the PM should instantly start working through that. Resetting them correctly, or working with the project team to re-plan the project to stay on track (the new track that is). This is were agile comes in handy. With waterfall, it is harder to get back on track (the old track usually, and then results in more track issues. But that is for another post).

The PM must excel at communication, and truly build a relationship of understanding with the client. There are whole books on how to do that, one blog post, especially from me, isn't going to cover it.

So, the PM tracks budgets, writes conference reports, and processes change control, but that is just paperwork. They are work products to support the business of a project.

The PM has a lot more to offer the client, and the project team. They can end up being a force for good, actually completely bypassing issues a 'run of the mill' PM might run into, and really make the client's experience with the project a great story.

There was one project I was on where a client disconnect happened over and over again. Part of this was due to the PM (who is a fabulous PM in my book) wasn't fully available for the project, part due to the day to day client having their own misunderstandings of what the real drivers were on the part of the executive sponsor, partly due to some global company politics, etc.

The first problem was when we had beautifully executed a visual and technical design for a self service EDI application. We finished on time, had a great result, and felt really good about doing a good job under a great deal of pressure. Now this project, which we were a small small part of had plenty of problems. It was a huge integration project, with a lot of newbies running the show. There were missed timelines (by months), immature use of off shore teams, exasperated executives, and all manner of other problems.

On the last day of the project, we deliver our final deliverables, and are in a great mood. The executive sponsor blows his stack. 'Why did we waste his time with this? When were we going to build it for him?'

It turns out that this giant team, with four chefs who didn't communicate with each other, suddenly told the executive sponsor that the timeline was ok, because not only were we going to design, but also build the front end. This would allow their super team of back end people to really hit the timeline this time. Here was the problem, no one told us, but the sponsor had that as the expectation.

So, our PM rolled up his sleeves, and got to work. Calming people down. Unwinding the ball of yarn that covered the truth. He was able to do this with just the sponsor in the room. He eventually came to realize what was going on. He then signed a contract with us to bust out the front end. Wiring it to the backend was to still be left to the first team, the backend guys.

Because we weren't actually in charge of the project (just brought in to do one aspect), we weren't in a position to avoid this. We were sucker punched by the actual project team.

Because of this, our PM recognized that we had skin in the game, wether we were supposed to or not, so he got completely engaged. When more slings and arrows came our way, he was able to step in and wave it away with the sponsor, and the client.

Years later, this client still calls me on occasion for advice, from a project with my former employer.

While I may have done a good job with the tech on that project, the real superman was the PM; keeping the client and project on the same track, freeing me to build cool stuff that allowed the users to kick ass.

 

Rule 1: A good PM doesn't just manage the project, but manages the client and the cilent's expectations.

Reflection on Ted Neward's Tech Predictions

Ted Neward has posted his predictions for 2007. I thought I would list them here, and add my responses to each. Please go read the original post. My comments will be in red.

  • General: Analysts will call 2007 the Year of the {Something}, where I bet that {Something} will be either "ESB" or "SOA". They will predict that companies adopting {Something} will save millions, if not billions, if only they rush to implement it now. They will tag this with a probability of .8 in order to CYA in case {Something} doesn't pan out. (Yes, I've read far too many of these reports--I'm personally convinced that each of the analyst companies has a template buried away in their basement that they pull out each time they need a new one, and they just do a global search-and-replace of "{Something}" with whatever the technology du jour happens to be.)
  • I couldn't agree more. Analyst companies don't provide any value besides providing a way for a bad excuse for a CIO/CxO to rationalize a big decision. They just need to pick the proper company that backs up their inner wish.

  • .NET: Thousands of developers will horribly abuse WPF in ways that can only be called nightmarish, thus once again proving the old adage that "just because you can doesn't mean you should" still holds. WPF's capabilities with video will prove, in many ways, to be the modern equivalent to the "blink" tag in HTML. This will provide some author with a golden opportunity: "WPF Applications That Suck". Alan Cooper will re-release "About Face", updated to include WPF UI elements.
  • I have been saying for over a year that WPF is a HUGE step forward for desktop app UI. It finally gives the window jockeys the power of web design. Unfortunately, it seems more akin to HTML 4 than to XHTML/CSS, but its a great first step. I also think that the first 12-24 months will be like the early days of web design. Remember those? Gray background, black text, and every client design session started with the 'designer' asking if the client wanted their logo to 'be on fire' or 'rotate'. The dev crowd will skill up and finally the people with great UI's in them will come forward, and finally have the tools to EASILY build them. Between now and then, there is a whole lot of UI bad. Microsoft should make every developer read Cooper's "The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity" before they install the WPF SDK.

  • .NET: Thousands of developers will look to Redmond for an answer to the question, "Which should I use? BizTalk, Windows Workflow, or SQL Server Service Broker?", and get no clear answer.
  • This is where I have to break with Mr. Neward. I think there is clear guidance now, but maybe that is because of my work with the BizTalk product team. Need a raw data shovel? Use SQL Server. Service Broker shouldn't be used at all (see lower down for my reasoning). Need workflow support IN an application or a composed system? Use WF. It's a building block, and a very good one. Need EDI, true EAI, a ESB/SOA platform as a server product? Use BizTalk. MS will of course build great tools, and leave it to the masses to use or misuse them as they will. The dev community will find it's way through this.

  • Windows: Microsoft will try, once again, to kill off the abomination that was called the Windows 95/98/Me line of operating systems, and will once again have to back off as industry outcries of protest (on behalf of little old ladies who are the only ones left running Windows 95/98/Me and probably haven't turned their machine on in months, at least not since the grandkids last visited) go ballistic.
  • Yes. And kill they should. I can't believe people at still using Windows 95. I can accept grandmothers might. And they can still use it. But there is no need to require MS to support it, at all. There are plenty of partners/companies out there that will be willing to support it, for a price. This is a reflection of a problem only Microsoft with OS's, that the other OS vendors don't have. Such a huge install base that they CAN'T move with the agility they would like to, or that others can.

  • Windows: Ditto for Visual Basic 6.0, except now the outcry will be on behalf of developers who aren't capable of learning anything new. Sun will use the resulting PR to announce Project YAVKRWMITT (Yet Another VB Killer Really We Mean It This Time, pronounced "YAV-kermit") on java.net. Meanwhile, efforts to make CLASSPATH into something a VB 6 guy actually has a prayer of understanding will go quietly ignored.
  • We have many clients moving from VB6 to .NET, and need a lot of help moving. I think the longer people wait, the harder for them it will be. Most are taking a life cycle approach. New apps are in .NET, and old apps are only moved to .NET when their lifecycle demands. Of course, maintenance costs need to be taken into account when discussion the lifecycle of a legacy app.

    Another interesting thing, is now that it is is hard to find skilled vb6 developers (most good developers have moved to .NET, and refuse to even pick up vb6 for a small project), that the VB6 bill rate is creaking up. This will rise through 2007, and then start to drop as the last VB6 application holdouts give up and move on to something else.

  • Java: JSR 277 will continue to churn along, and once the next draft ships, publicly nobody will like what we produce, though quietly everybody will admit it's a far cry better than what we have now, and when it ships in JDK 7 will be adopted widely and quietly.
  • I don't know enough about Java to even contemplate this.

  • Java: Thousands of new ideas and proposals to extend the Java language in various ways will flood into the community, now that developers can start hacking on it for themselves thanks to the OpenJDK. Only a small fraction of these will ever get beyond the concept stage, and maybe one or two will actually be finished and released to the Web for consideration by the community and the JCP. Thousands more Java developers craving Alpha-Geek status will stick a "Hello, world" message into the compiler's startup sequence, then claim "experienced with modifying the OpenJDK Java compiler" on their resume and roundly criticize Java in one way or another by saying, "Well, I've looked at the code, and let me tell you....".
  • Again, I don't know crap about Java, or the community, but I imagine that the release of OpenJDK will result in one of two things. It will either be seen as a wondrous move (most OSS monks believe this already) and will re-invigorate the slowing march of Java adoption, or it will splinter and confuse the Java market more than it already is. We do have Java clients, and project (I just don't have a deep understanding of the platform), and they already struggle with multiple application servers, and their differences.

  • .NET: Somewhere, a developer will realize that SQL Server 2005 can be a SOAP/WSDL XML service endpoint, and open it up as a private back-channel for his application to communicate with the database through the firewall "for performance reasons" (meaning, "So I can avoid having to talk to the app server in between my web server and my database"). With any luck, the DBA will kill him and hide the body before anybody can find and exploit it.
  • Yes, Yes, a thousand times Yes! May this be yelled from the rooftops by all developers everywhere. The database is for storing my data. Nothing else. I am surprised the DBAs haven't risen up against the SQL team and complained their wondrous platform has been sullied; no: contaminated, with application server-like features. There is no need for them to be there, and only leads to a waste of MS's money (that dev effort could of been used to actually provide valuable SQL features, or been directed to be part of their app server products instead). I don't even really like the idea of SQL Reporting Services. Great tool. Great use. It shouldn't be part of SQL Server. It should be it's own product, that runs on something else (the app server that isn't here quite yet?).

  • General: Yet Another Virus That's Microsoft's Fault will rip through the Internet, and nobody will notice that the machines affected are the ones that aren't routinely administered or receive updates/patches. Companies will threaten Microsoft with million-dollar lawsuits, yet will fire none of their system administrators who lovingly lavish whole days tuning their Linux IRC servers yet leave the Windows Exchange Server still running Windows NT 4.0.
  • Agreed. It is amazing how the bar MS is held to is different than anyone else. I wonder when malpractice lawsuits will apply to technology consultants? Not that I am looking forward to that, but there are so many dysfunctional teams and IT staff in this industry, that shouldn't be anywhere near technology. If only there was a gene test.

  • General: Interest in JSON will escalate wildly, hyped as the "natural replacement for XML" in building browser-to-server connections, owing to its incredible simplicity in expressing "object" data. Folks, JSON is a useful format, but it's not a replacement for XML (nor is XML a replacement for it, either). What made XML so popular was not is hierarchical format (Lord above, that's probably the worst part of it, from where we as developers sit), nor its HTML-like simplified-SGML syntax. What made XML interesting was the fact that everybody lined up behind it--Microsoft, Sun, BEA, Oracle, IBM, there's not a big vendor that didn't express its undying love and devotion to XML. I sincerely doubt JSON will get that kind of rallying effect. (And if you're going to stand there and suggest that JSON is better because its simpler and therefore more approachable for developers to build support for themselves, quite honestly, I thought we were trying to get out of developers building all this communications infrastructure--isn't that what the app servers and such taught us?)
  • JSON is nice. XML is beautiful. I constantly tell anyone who will listen that we need to get out of the plumbing business, and focus on writing code that provides value to the client. That is why we have BizTalk, WF, WCF, Spring, etc. I think frameworks are powerful, but their design and development should not be part of a normal enterprise development project, but one of their own.

  • General: Interest in Java/.NET interopability will rise as companies start to realize that (a) the WS-* "silver bullet" isn't, (b) ESB, XML, and SOA are just acronyms and won't, in of themselves, solve all the integration problems, and (c) we have lots of code in both Java and .NET that need to talk to each other. This may be a self-serving prediction, but I got a LOT of interest towards the end of this year in the subject, so I'm guessing that this is going to only get bigger as the WS-* hype continues to lose its shine in the coming years.
  • There are several kinds of clients. Those that pick a platform, and for better or worse stick to it ruthlessly. If they are a MS shop, and what they are building could be done better with something else, they will still stick to the MS tools, and vice versa with Java. While there is much to be said for this (fewer platforms == less maintenance and training costs, generally), there are times when it is prudent to use best of breed for solutions. All along there is this other camp that hasn't met a platform they didn't like. Four different platforms, three different J2EE app servers, two integration platforms, and four RDBMS platforms. Aaah, the joy of a spectrum, and helping clients find the right balance.

  • Ruby: Interest in Java/Ruby and .NET/Ruby interoperability is going to start quietly making its presence felt, as people start trying to wire up their quick-to-write "stovepipe" RAILS apps against other systems in their production data center, and find that Ruby really is a platform of its own. RubyCLR or JRuby may be part of the answer here, but there's likely some hidden mines there we haven't seen yet.
  • Not really any comment here. I know, you are shocked.

  • Languages: A new meme will get started: "JavaScript was that thing, that little toy language, that you used to do stuff in the HTML browser. ECMAScript, on the other hand, is a powerful and flexible dynamic programming language suitable for use in all sorts of situations." Pass it on. If you get it, don't tell anybody else. (Don't laugh--it worked for "The Crying Game".) It's the only way JavaScript ECMAScript will gain widespread acceptance and shed the "toy" label that JavaScript has.
  • What Ted is saying, is that like VB, the term 'javascript' has baggage. I think the best thing to ever happen to js is Atlas, and how they turned it into a fully OO language along with the browser normalization layer (much like a HAL). I know there is a movement away from OO, and such, but to me, this has made js so much more useful. Although, and tool/framework that helps minimize the use of js on my part (under the covers is fine) the better. Its a beast to work with and debug.

  • Languages: Interest in functional-object hybrid languages will grow. Scala, Jaskell, F#, and others not-yet-invented will start to capture developers' attention, particularly when they hear the part about functional languages being easier to use in multi-core systems because it encourages immutable objects and discourages side effects (meaning we don't have to worry nearly so much about writing thread-safe code).
  • I presume this will be correct. I don't go looking for other languages like other people. I have to focus most (but not all) of my attention on the tools and platforms my clients need to have their solutions build (based on their environment, and the best tool for the job.) While I feel there is a great amount one can learn from languages and platforms that aren't your own (the reason behind my support and effort helping organize CodeMash), you still need to master the tools that pay the bills. An eye forward, and an eye on what you are doing.

  • Languages: Interest in Domain-specific languages will reach a peak this year, but a small backlash will begin next year. Meanwhile, more and more developers will realize that one man's "DSL" is another man's "little language", something UNIX has been doing since the early 70's. This will immediately take the shine off of DSL's, since anything that we did in the 70's must be bad, somehow. (Remember disco?)
  • I agree that interest in DSLs will rise a great deal this year. I don't like the term peak, as that implies a decline thereafter. I think that interest will rise, and that they will become mainstream (at least on MS platform) due to their inclusion into the toolsets, as well as the rich ecosystem of tools built with DSLs. DSLs will help my team be "Better, Faster, Cheaper" this year. Tools make you more productive, which is important for everyone, and DSLs help you build better tools, quicker.

  • General: Rails will continue to draw developers who want quick-fix solutions/technologies, and largely that community will ignore the underlying power of Ruby itself. The draw will start to die down once Rails-esque feature ideas get folded into Java toolkits. (Rails will largely be a non-issue with the .NET community, owing to the high-productivity nature of the drag-and-drop interface in Visual Studio.)
  • I think, and my opinion should matter much here, that the attention Ruby gets is unhealthy right now. People get excited, there is A LOT of pressure to investigate it and sing its praises, but people are paying attention to the wrong parts of Ruby, and missing what Ruby really has to offer us. I think it is mostly a maturity problem, and as the ecosystem stabilizes and exits the buzzword stage, maturity will set in, and people will start to truly Grok it. How will you know this when it happens? When sessions at conferences about Ruby stop showing off the power from a command prompt, and start talking about real solutions to real problems we need to solve. Until then, while a great thing, it will still be thought of as a plaything. There is more to Ruby. People need to get out of the spinning logo stage though.

  • Java: Interface21 is going to start looking like a "big vendor" alongside BEA and IBM. I was talking with some of the I21 folks in Aarhus, Denmark at JAOO, and one of them casually mentioned that they were looking at a Spring 2.1 release somewhere in mid-2008. Clearly Spring is settling into eighteen-month major-version release cycles like all the big (meaning popular), established software systems have a tendency to do. This is both a good thing and a bad thing--it's good in that it means that Spring is now becoming an established part of the Java landscape and thus more acceptable to use in production environments, but it's bad in that Spring is now going to face the inevitable problem all big vendors face: trying to be all things to all people. This is dangerous, both for Interface21 and the people relying on Spring, largely because it means that Spring faces a very real future of greater complexity (and there are those, myself included, who believe that Spring is too complex already, easily on par with the complexity seen in EJB, POJOs notwithstanding).
  • Java?

  • General: Marc Fleury will get a golden parachute from Red Hat (at their request and to their immense relief), and hopefully will retire to his own small island (might I suggest Elba, la petite corporal?) to quietly enjoy his millions. A shame that the people who did most of the real work on JBoss won't see a commensurate reward, but that's the way the business world works, I guess.
  • Another chapter in the free wheeling, free love OSS movement versus 'The Man'. Can we stop this crap, and focus on building great stuff and helping uses kick ass? These 'camps' are worse than the Dems vs Republicans crap that has swallowed the political landscape.

  • General: Some company will get millions to build an enterprise product on the backs of RSS and/or Atom, thus proving that VCs are just as stupid and just as vulnerable to hype now as they were back in the DotCom era.
  • Again, I don't have a lot of authority in RSS. Its a simple protocol. Big deal. "But Brian," you say, " it allows for such wondrous social change, etc.". Yeah, don't care. I have other stuff to focus on.

  • General: Somebody will attempt to use the phrase "Web 2.0" in a serious discussion, and I will be forced to kill them for attempting to use a vague term in a vain effort to sound intelligent.
  • As soon as we are done flaying the people who use SQL Server as an application server, we should then start on the "Web 2.0" idiots. I will smack the next person who seriously uses that term.

  • Web clients: Ajax will start to lose its luster when developers realize the power of Google Maps isn't in Ajax, but in the fact that it's got some seriously cool graphics and maps. (Or, put another way, when developers realize that Ajax alone won't make their apps as cool as Google Maps, that's it's the same old DHTML from 1998, the hype will start to die down.)
  • Even with Ajax.net, and Atlas, etc, Ajax is still a challenge to build with and debug. It will really help as we focus more on composing systems, as opposed to stove pipe systems. The tooling just needs to catch up.

  • XML: Somebody, somewhere, will realize that REST != HTTP. He will be roundly criticized by hordes of HTTP zealots, and quietly crawl away to go build simpler and more robust systems that use transports other than HTTP.
  • I really don't like using HTTP as a transport for other stuff. It's like hauling around freight in your conversion van. It works, sort of. HTTP is abused. No one will come out with a better transport, because HTTP is baked into so much stuff, and is left so wide open. I think putting all of this stuff on HTTP is a huge security flaw.

  • XML: Somebody, somewhere, will read the SOAP 1.2 specification. H.P. Lovecraft once suggested, loosely paraphrased, the the day Man understands the nature of the universe, he will either be driven into gibbering insanity, or flee back into ignorance in self-preservation. Ditto for the day Man reads the SOAP 1.2 spec and realizes that SOAP is, in fact, RESTful.
  • This just made me LOL. It's true, so very true. I don't even think the people who wrote the spec, read the whole thing. I hear that Dumbledorf dies in the end though.

  • Security: The US Government will continue its unbelievable quest to waste money on "security" by engaging in yet more perimeter security around airports and other indefensible locations, thus proving that none of them have bothered to read Schneier and learn that real security is a three-part tuple: prevention, detection, and response.
  • Agreed. Security doesn't exist. Just a toolbox of ways of defeating known and presumed methods of attack. This goes for terrorism in the physical world, and for hackers in the digital world. The digital world learned years ago that perimeter security is worthless, and that defense in depth is what is important.

  • Security: Thousands of companies will follow in the US Government's footsteps by doing exactly the same thing. (Folks, you can't solve all your problems with cryptography, no matter how big the key size--you just end up with the basic problem of where to store the keys, and no, burying them inside the code isn't going to hide them effectively.)
  • See above.

  • Security: More and more rootkits-shipping-with-a-product will be discovered. We used to call it "getting close to the metal", now it's a "rootkit". With great power comes great responsibility... and, as many consumers have already discovered, with great power also comes a tendency to create greater instability...
  • Funny how rootkits have been around for so long, and now everyone knows, or thinks they know, what they are.

  • General: Parrot will ship a 1.0 release. Oh, wait, hang on, sorry, I bumped into the crystal ball and accidentally set it to 2017.
  • Must be a Java thing.

  • .NET: Microsoft will ship Orcas (NetFX 3.5). (Sorry, crystal ball's still set on 2017. Trying to fix it...)
  • An Orcas CTP was just pushed to MSDN.

  • .NET: Vista will surpass Windows XP in market penetration. (Let's see, almost got it set back to 2007, bear with me... There. Got it.)
  • I actually love Vista. I have been running it through all of the series of beta's/ctp's/rc's, etc. It is truly a great product. Nor perfect, and nor should anyone expect it to be perfect.

  • General: I will blog more than I did this year. (Hell, I couldn't blog less, even if I tried.)
  • I to will try to blog more this year.

  • General: Pragmatic XML Services, Pragmatic .NET Project Automation and Effective .NET will ship. (Wait, is the crystal ball still on 2017...?)
  • If you are familiar with any of my talks, you will know that I favor the pragmatic type of talks, like in my Agile deck. There are some great Agile/XP talks out there about the pillars, believes, etc of Agile. This gets the crowd excited, and they run home to do it, and don't know where to start. I link to take the Hands On approach, and show people how we do it, some concrete examples, and real stories/experiences. I plan on expanding the series to include Hands on ESB/SOA, as well as others. There are so many pie in the sky talks on both ESB and SOA (and I know some of my MVP architect brethren are seething that I even use the term ESB), and I want to show and talk about what we have built, what worked, and what didn't, and what practices we used, and which are just ivory tower pigeon poop. As a side note, the recent publication that talked about the SOE Maturity Model (the MS Architecture Journal? not sure where I read it) was a great read, and put into writing what I feel about SOA architecture and growth/maturity. Its makes a great tool when talking to clients about where they are, and where they do and do not want to head.