• EnvDTE
• Microsoft.VisualStudio.TemplateWizardInterface

As I reach the 1/2 point in my career developing software, I started thinking about where we are at in the industry of Software Development and how much progress (or lack thereof) as well as some observations and things I’ve learned.  If you would have asked me 10 years ago if I would be at the half way point in 2009, I would say, heck no, I’ll be retired and doing this for fun…so much for the internet bubble and stock options.

 The following are some observations and thoughts on some things I've learned at the different positions and work I’ve done with the last 19 years.  If you make it to the end of my "ramblings" drop me a note and let me know what you think.

After graduating from Minnesota State University in 1990 with a degree in Computer Science and Electrical Engineering Technology, my first job was as a Software Engineer responsible for designing and programming embedded systems for weight and force measurement devices.  We had about 5-6 Software Engineers on staff, each week we had meetings to discuss ways we could improve the process of developing software.  This was a long and painful process where our primary objective was to build consensus on development standards.  We started with coding conventions for FORTH, C & C++.  What made this extremely painful is that as we all had opinions (although only a couple of us actually programmed in C/C++ at the time) and at one point we spent weeks discussing putting curly brackets around single lines after an if statement.  Anyway, my point is that although it was important to build consensus this approach wasted way too much time, and although I think we did make some modest gains, these meetings were probably better held in an academic setting.  I had an excellent mentor and the company probably still doesn’t want to know the number of hours the two of us spent shooting the sh*t discussing software engineering and software architectures instead of programming devices.  Luckily the two of use seemed to be the only ones to ship on time so I guess they didn’t mind too much.  I considered those years as almost a “Masters” level education.  Some of the observations/lessons from this position:

• Designing the hardware, writing the low-level drivers and then the software that made the microcontroller do something meaningful is truly an enlightening experience.  It still influences how I program in high level languages such as C# today.
• Another invaluable lesson learned at this job was the difference between sales and marketing.  And the good, the bad and the ugly of working with other areas within a company.
• Get your developers in front of the customer and in the real world as much as reasonably possible.  It puts a different perspective on things when you see your software run a huge rock smasher or rail-road train scale instead of turning on $0.05 LEDs in the right sequence that simulates the actual hardware.  This is also true if your developers experience is limited to only seeing a 1 with a bunch of zero’s that represents a decimal data type on a sales order instead of a real order for a gazillion dollars that represents real money.  It's an eye opener to see how real users actually use your software.
• Keep your developers coding, and then have them code some more and when they are done doing that, have them code a little more.  As with any craft you get better with experience.
• If you don't know where you are going a map is no help, developers shouldn't be the ones making up the requirements, if they are get them in front of the customer as much as possible (note the conflict with the previous item)
• Software estimating even on small projects is very difficult.  Estimates from developers should be doubled.
• When marketing drives certification efforts such as ISO9000, the results are very shallow.

Next I went to work for a Sales Force Automation company, starting out as a software engineer and ending up with the title of “Director of Tools and Technology”.  I had two primary roles as a director, first was to dispatch fire fighting teams get projects out of the ditch and the second was to put in a set of processes and tools to help keep those projects out of the ditch in the first place.  I had the luxury of hiring my own senior staff.  I’m a firm believer that right people are single most influential factor in the success for failure of a software project.  I actually found that people with engineering degrees in some respect were better suited for this type of work than ones with a pure comp-sci degree.  In my previous job I was introduced to the classic Managing the Software Process by Watts Humphrey  this is a classic must read book.  A number of concepts seemed to make considerable sense when working with large projects with a duration of 1+ years and teams of 6-12 developers.  Much more so than the single person 3-4 month projects at my previous position.  One of the lessons learned here is that different types of software require different set of processes and talent.  Some other observations from this position:

• Developing large systems is just plain hard, there is no silver bullet, but with the right people it is possible and can even be fun.
• Team building is important to the success of your project.  Finding the right chemistry is worth the effort, bad apples or “negative producers” must be swiftly removed from the team.
• It’s really all about data, for the type of systems we were building (and even the ones I build today) getting the data model right will make or break your project.
• While the business analysts are figuring out what to build, it's a good time to have your senior and lead developers plan out your architecture and figure out what common functionality needs to be organized into the application frameworks.
• It's worth the investment to build scaffolding to test your application.  At the time we weren’t doing any formal unit testing, but had all sorts of little tools and utilities to help make our life easier.  Really a necessity when the MFC compiler took 45 minutes to do a full build.
• I was formally introduced to “Design Patterns” and the GoF.  Coming from an engineering background, I had always thought Software Development needed to mature and “Design Patterns” were going to be our building blocks.
• Platform Independence sounds good when on the marketing cut-sheet’s but in reality…well…you know the story here.
• Senior, top level management buy-in and participation is absolutely critical to the success of any software process improvement effort.  The primary reason for this is there are more departments in your organization other than development and everyone needs to play together nicely to ensure successful projects.
• When spec’ing and selling multi-million dollar projects, make sure you have representatives from the dev staff involved with pre-sales.  Without that I’ve found there is usually an expectation mismatch, this is true in smaller projects but critical in larger ones.
• Our company was organized into Product and Professional Services divisions, using real world requirements from Professional Services goes a long way to help product development planning.
• There should be an inverse proportion of the amount of code you write with respect to your level within the management food chain.  When I started as a software engineer, I spent 90% of my time coding.  As a director, I spent about 5% coding if I was lucky.  The challenge here is to keep your skill sharp, you need to code, period.  To be a good manager you need to manage period, if you are coding you are doing your employees a disservice.
• In our industry, a manager works for their employees.  That is to say a managers first and foremost responsibility is to equip her coders with everything they need to succeed and aggressively remove road blocks.
• Although difficult, setting and managing expectations is critical to the success of delivering software.
• Although I’m sure the agile folk’s won’t agree, I’ve found the longer I can stay out of the “problem domain” and keep working on my application frameworks (factoring out common/abstract functionality) the sooner I’ll ship my software.  This deserves another post to explain in more detail.
• Technical solutions generally don’t work to fix process problems
• Towards the end of my time there I had a keen understanding of why executives “don’t like surprises”.
• If you get a stock option grant (especially one big enough to retire with) it's a good idea to get a lawyer involved early on so you don't end up with Toilet Paper.
• It’s all really about People, Process and Technology

PPT Solutions, LLC

Three of us left the Sales Force Automation company and started our own venture it was called PPT Solutions (People Process & Technology, in that order as we liked to say).  We put together our business plans, cash flow projections and since this was in the internet bubble we were convinced there is no way we could fail.  Although I wouldn’t consider this business a success, we did manage to ship a product, and I did learn a lot about going into business for yourself.

• We were told going into a business partnership with friends was a bad idea, we thought we were different.  We weren’t.  The reality is that someone needs to be in charge and equity needs to be based upon contribution to the company.  Friendships complicate this, especially in our industry where we think we are all “rock-stars”.  Eight years later the wounds from this are finally healed.
• Sales is critical, sales is not easy, sales requires a different skill set than developers, we sold our product into Imation (3M Spin off and electronic media company) I think we landed the sale because I was sleeping with the global sales training manager (who I've been married to for the last nine years and still madly in love with).
• Although it sounds good to get a sale and then use that money to develop a product and then market it that way, in reality the product will contain all sorts of very specialized features for the company paying for the majority of the effort.  Care should be taken so that specialized requirements don't contaminate the core product.
• Make your estimate than double it, both time and dollars
• It’s a double edged sword working out of your house.  It's nice, but it requires discipline to stay focused.  Having weekly goals is a good idea.  You will probably also be working on weekends to a certain extent.  Do whatever possible to separate your work week from your weekend, this helps burn-out.
• If you partner with other people to start a business, clearly define expectations and responsibility up front.

Next up was a small startup, let's just say I don't have a lot of good memories from that place.  This wasn't really a technology learning experience, however I did learn how to successfully get what I needed in a difficult environment to ship software.  The company came in at the tail end of the internet bubble and had visions of making a pile of cash with very little effort and a lot of 0's and 1's in the right order.  Enough said…moving On….

That takes me up to what I'm doing today, Software Logistics, LLC.  My company.  I don't have any employees, but use contractors as necessary.  I seemed to have found a nice niche.  I spend about 90% of my week coding.  Although I do miss the thrill of leading a team into battle, I guess the pure joy of carving out excellent software makes up for it.  I've worked with very small companies and very large companies during the past eight years.  Each has their strengths and weaknesses and enjoy working with both.  This has been a great learning experience and I’ve shipped a number of projects in the process.

• To get started, networking and word of mouth is very important.  Even more so is networking with the right people.  There is time for friends and time for business.  As with my previous venture, these don't often mix very well.  That doesn't mean you can't have fun with the people you work with, however since this is going to be your primary source of income it's important to stay objective.
• Even though you are out on your own, that doesn't give you an excuse to cut corners or skip basic SCM principles such as source control, issue tracking, build environments etc…  What's nice about being on your own is you don't have to reach consensus and you can experiment with different processes and technologies.  Although still in evolution, my CI and deployment environment rivals if not exceeds most of companies I work with.
• Invest in yourself.  I attend at a minimum two conferences a year.  Even those these are on my own nickel this is a must.  Going to conferences allows you the time to focus on what's new and get a quick overview of a wide variety of technologies.  Don't expect to become a master at any of these, but you should get an idea of what's real and what's worth investing more time in.  Even more important is getting a sense of that latest flavor of the month so you don't waste your time or sabotage your project.
• If done right, it's generally important to come off strong in the first 15% of the project and finish strong in the last 25%.  This doesn't mean you go "dark" but during the development phase it's a balance between keeping your client comfortable with the progress and staying out of the details enough to keep on your schedule.
• Communications is critical, if I had to say there is one common denominator across all the clients I've worked with is that they all need to improve their communications.  There needs to be a balance between using tools such as a defect tracking and verbal communications.  SCM work tracking tools are good for capturing and managing a large amount of details, however even with a "priority" ranking, they just don't convey the sense of urgency and importance that verbal communications can provide.
• When in a meeting (even in sunny Tampa) no-one likes to see your arms, wear a nice button down dress shirt and khaki's.  Remember you are a professional, impressions matter, especially when negotiating the yearly rate increase.  I don't think it's important to drive a BMW, but you should project a feeling of success.
• You can't generally rely on the QA of your clients.  If you can't do it yourself (which is very difficult if not impossible) hire someone and get a good issue tracking system.  I really like Visual Studio Team System, if you have a premium subscription, you should be able to leverage the workgroup license.
• Hold frequent status meetings, you should run these meetings, always have an agenda.  Set the expectations as to what you will cover in your agenda and ask for feedback if they have any concerns.
• Respect your clients time, most people have more work than time.  At the start of the meeting ask for how much time you have and adjust your schedule accordingly.
• You are viewed to be the expert, and to be successful, you should be a jack of all trades and a masters of a lot of them.  However it’s impossible to know everything.  If you don't know something don't BS your client.  Most of the time the people you are working with can tell, you need to keep your credibility and trust.  If you don't know something, find out and make sure you follow up promptly.
• Your demos will almost never go as planned.  I remember one demo that I practiced a number of times and it worked flawlessly, I got to the client site and they had custom DNS settings on their internal network.  It broke my demo.  Think quick, think on your feet, and adapt, in my case a simple tweak of the HOSTS file was all that was necessary.
• At all costs do not get involved in company politics.  All companies have them.
• Don't expect the same level of support/services from other people at your client as you did when you worked as an employee within a company.  People are generally overworked and requests from the consultant come after requests from their internal managers.
• If you are billing hourly, make sure you have a good system for capturing and tracking your time, even if your client doesn't ask for it.  Never over bill your client, if your client isn't paying you enough to live on, ask for more money find an additional or a different client.  Remember it's your name on the line.
• If a client pays you to build software, they own the source code (unless you work out a different arrangement).  Don't use that source code in a different project or for a different client without their written approval.  That isn't however saying that you can't re-implement the same algorithm, they own the source, not the concept with certain obvious exceptions such as industry or trade secrets.
• I've found that there is no right answer to the right amount of documentation you should provide.  I had one client that complained about the level of documentation I produced.  When it came down to detail and specific documents with senior management, I could always produce the documents in their repository and the response was "I didn't know we had that".  I don't think the documents were even looked at.  I guess my point is for a developer, documentation is no fun.  If no one is going to read it it's your call on how much to deliver.  It's good for CYA.  Another client I have uses a WIKI for documentation, nice and simple, yet effective.  If your client doesn't have one, set one up for them on your server.  If it gets traction install on their server.
• Don't skimp on your computer setup and hardware.  Time is money, would you rather spend your time installing and configure software, or would you rather cut code and get paid.
• I've found that using a tool like VMware Workstation works great for doing client work.  I have a base setup that has all generic development tools.  I can than copy that base VM and configure it with the specific tools and source to work on client projects.  An added benefit here is that at the end of the project, you can always just give them the VM and they can pick up where you left off.  My main dev boxes generally are multi-core and very fast, when I'm working in a VM, I just can't tell a difference.
• If the environment is right, offer more than you ask for, I really enjoy mentoring young developers, and showing them new tools, technologies and techniques, be careful here though not to step on other internal developers toes.

If I haven't bored you too much and you made it this far (I'm a coder not a writer), I can offer some general thoughts of where we are as an industry:

• Every project is different, yet there are many similarities amongst different projects.  If anyone says they have the one true way to develop software, you can tell them, ok, whatever, let me buy you beer and let’s poke holes in the process for what I’m working on.  There are also differences in techniques required when working on the same project.  An example is a non-trivial LOB application, there is the application frameworks, data layer, business objects, UI library, each of these is different and requires a different approach and the investment in time and design.  My point here is that there seems to be a lot of great work done developing tools, technologies and processes, we just need to start doing a better job of discussing where they should be used.  And general sweeping statements such as any code with out tests is considered “legacy” (read crap) don’t do much for helping us bring the right tool to the right problem.
• I'm not sure there are any metrics out there, but I would suspect the majority of developers out there work on what I would consider Line of Business (LOB) type of applications.  Generally the most difficult part of this development is the ability to track and manage changes to the business rules and requirements.  I've seem a few implementations, that probably were much more complicated than need be.  Sometimes it's fun to pick up the latest technology or pattern when all you really needs is some simple OO principles and a nice Forms over Data application.  Some of us need to build Jaguar's and some of us need to build F-150's.
• I mentioned it above, but one of the core problems I see in our industry today is the lack of effective communications, this was true back in 1990 and is still true today.  This may not be true of all companies, but I would suspect it is for the majorities of the companies out there.  I think Software Development can be described as managing thousands of little details, understanding how they act together and how to effectively communicate those details with others.  We do this by a series of translations; users translate their needs to a user advocate, the user advocate translates those needs to a business analyst, the business analysts turns those into requirements and prioritizes, the developer picks up those requirements, the develop translates the requirements to a design, then the design into code and finally the compiler turns the code into something that can run on a computer.  Even if you effectively implement agile techniques (which I suspect most companies that say they are agile really aren't) this is just plain difficult.  Take into account Fredrick's Brooks law of adding man power to a late software project makes it later and you get an idea of the scope of the challenge.  So, you say, what's the answer?  I'm not sure there really is one.  What I do know is some people are better at this than others, I think this is probably an important attribute that is overlooked when hiring.  Sure you may be a rock star coder, but if you don't code the right thing, oops…what's the point?
• Everyone in our industry thinks they are a "Rock Star" in reality very few people are.  Another theory from the class Mythical Man Month is that there is an order of magnitude between an average developer and ones that are truly "Rock Stars".  I’ve found this to be the case.  On some big projects I’ve worked on I’ve found that 20% of the team completes about 80% of the work.  The trick that I've learned is accepting that I'm probably not one of the “Rock Stars” and as the Verizon quote goes try to "Make Progress Every Day" into becoming a better developer.  This includes reading all the classics, writing tons of code that gets into production.  Coding for fun generally glazes over the details, details are what makes software hard.  I've also found it to be beneficial to work with really smart people, they push you, you push them.
• I still keep in contact with the ninja's that worked for me to setup what we had thought was a decent development organization.  Since then, we went down two different roads, they went to work at a huge enterprise, where the basic idea is to manage change and make sure the gazillion lines of code compile and bugs don't cost too many millions of dollars per year.  I'm cuttin' code pretty much every day.  I don't know which path is better, I'm not sure there is a better path, I know I love what I'm doing now.  When we get together a couple times a year, it sounds like progress is being made in managing change, however the systems are getting more and more complex.  The net result is that things are just as screwed up as ever and the same fires we put out back then are still flaring up however they are handled much better.  Kudos to them, I have a lot of respect for what they do.
• It appears that more and more companies tend to rely on libraries and third party and open source technologies.  I think this is both good and bad, if you are working on a small 1-2 month project go ahead and use the 3rd party building blocks.  If you are working on a large system, it may be better to re-invent the wheel.  I think a good example of this is your Data Access Layer, if you are doing a small one off type of project absolutely use something like Linq 2 SQL or NHibernate.  If you are working on a fairly large project with a number of developers, it may be worth it to carve out your own DAL.  This is a non-trivial process, but 6-8 months into the project, you should recoup the investment by having exactly the feature set you need and understanding the inner workings of the critical piece of technology.  Spend the time up front, think through your architecture and requirements.  Realize that those 1/2 hour demos you saw where someone created a CRM site with just 5 lines of code, probably leaves out a considerable number of details.  Sometimes just dropping in a library introduces problems as noted by Joel Spolsky's Law of leaky abstractions. 

Well I guess I should probably clo se as I could ramble on for another few pages, I think in summary I would have to say that our industry is maturing with new processes, technologies and techniques but at the same time the systems are developing are getting much more complex so I would say our overall progress as an industry is probably flat.  At one time I had thought we would mature to a more engineering approach to delivering software but I think with the dynamic nature of the problem space and technologies, I'm not convinced that will happen anytime soon.  As to being at the 1/2 way point in my career, I’m still trying to build the “Killer App” who knows….

-ec  

I belive the following is accurate for developing 95% of business applications:

1. People buy software to solve problems, that can be making their life easier, making money or providing pleasure (don’t read too much in to that J )
2. Features enable solutions to problems.
3. When we write software, we build features.
4. With the right level of abstraction there is a common and finite set of features to be implemented in code.
5. Applications should be built by tailoring features to solve a user problem. 
6. If tailoring features has to be done by writing code, so be it, but this is very costly in terms of time and money.
7. It’s preferable to have this done via configuration.

-ec

Got a great tip from listening to the pod cast at http://www.stackoverflow.com/ (if you don't subscribe you should!).  Jeff Atwood in passing mentioned a program I've been looking for, for a long time.  It's called WinSplit Revolution.  I'm big time into multiple monitors, here's a picture of my previous setup, my current one is similar, but have a 24" as my main monitor, then two 21" on each side and finally a 900x1440 off to the left.

• My center monitor is used for editing source code editing, my primary source of revenue. 
• Left 21" monitor has all the extra VS.NET windows such as solution explorer, output, error windows etc...
• Right 21" monitor has the output of the project I'm working, usually have IE and Firefox open.
• I recently added back in the far left monitor, a 900x1440 in portrait mode.  On this monitor, I've got my email and Debug View.

Anyway back to the WinSplit Revolution, this program uses a CTRL-ALT-NUMPAD KEY to position the current quadrants on the screen.

Check this one out, you won't be sorry!

-ec

Putting your Trust in Metrics

I'm a big fan of automating as much as you can, but blindly automating processes controlled by metrics may cause more problems than they solve.  The idea behind capturing metrics or in the case I'm currently working on, writing a suite of unit tests is to automate the testing so I can make changes at-will, run my unit test and know everything is still working good.  If I come to rely on these unit tests (or really any sort of metrics) to help me make business decisions as to when I am code complete and ready to ship;unless I'm 100% sure that the unit tests take into account 99.99% of all the edge cases; I'm doing the recipients of the software a disservice.  As an efficient coder, I want to take what the customer tells me they need and turn it into the compiled bits that successfully solve their problem in a straight of a line as possible.  Unit testing and other software related automated processes go a long ways to helping ensure an efficient path, but as these automated processes are developed we need to pay special attention to make sure these are complete.  In a large sense, if you are capturing KPI or Key Performance Indicators about your organizations performance, are you sure that the core measures you capture are indeed complete and accurate?  Remember the purpose of capturing these metrics is to influence business decisions.  If your metrics are not accurate or your measures just can't be trusted, there are three core problems that this causes.  First it clouds the judgment of the people directing the efforts, they may think they need to do A, but the metrics tell them B really needs to happen, A is clearly the right thing to do, but since B is out there as a potential solution it may dilute the affect of implementing A.  Second it puts in place a false sense that you are indeed doing something to solve your problems and all you are really doing is delaying the true solution costing the most valuable asset in software development, time.  Finally it takes time to capture metrics and if done properly it is a great tool.  If your metrics are worthless you waste the peoples time building the infrastructure to capture the metrics, you waste the peoples time to capture the metrics and you may even unintentionally sabotage future metrics capturing initiatives.

In a previous post I discussed the race car analogy, where the drivers have a significant amount of safety gear in their cars.  They need to be 99.99% sure that if they get in an accident the gear will do it's job and protect them.  If they can rely on their gear, they can take more risks to give themselves a competitive edge.  Are your sure the test cases, scenarios and metrics your are employing would help you prevent or survive a crash and give you a competitive edge?

-ec

DevConn 2007

I had a hard time convincing my self to go to Fall DevConnections 2007 in Las Vegas.  I was really glad I went, I think I'm finally feeling that I'm on the tail end of the learning curve with the new technology releases from Microsoft.  I can't by any stretch of my imagination an expert in any of the new technologies but at least with some recent development experiences and attending numerous sessions over the past few days at think I've got a good lay of the land, at least to a point where I have a good sense of the capabilities of the new technologies and should be able to match up a problem to the right solution. 

Here are some of my findings from this conference:
1) I'm anxious to start using VS.NET 2008 (to be released later November), specifically I'm interested in the better support for developing AJAX sites with intellisense and script debugging.  I'm also interested to see the performance enhancements in the new product.  I'm starting to get a little frustrated with some performance issues in VS.NET 2005.

2) I'm starting to "feel-the-love" with Silverlight 1.0.  Although it's extremely exciting to think that Silverlight 1.1 can be programmed with any .NET languages instead of just JavaScript as in 1.0, I'm just not there yet for 1.1.  I like it that there is a nice and small 1-2MB file that can be loaded and installed with little to no friction is great for 1.0, but although I appreciate the ambition of moving .NET into all the different worlds with Silverlight 1.1 I think there might be too many moving parts.  I think the XAML Browsers applications are probably a better alternative...we will see, I sincerely hope to be proved wrong :).

3) I think I'm starting to feel a little better about LINQ as well.  In the past LINQ seems to have been presented as a completely different way of working with data, well yes it is, but in demos I've seen this was going to start leaking into the UI layer.  It seems like there are two really different uses for LINQ, the first working with pure objects via collections of different sorts, and the second is LINQ to SQL.  As with my previous post, it seems like for the most part we should let the Database handle the getting/filtering of data and that is what LINQ to SQL does (saw some awesome demos of seeing the SQL that LINQ generates and the execute it).  I'm still not sold on the other approach (at least in the 90% apps that sit on top of a database) where we use LINQ to work with collections of objects.  I can see some edge cases where this might be kind of nice, but I just can't see this in the vast majority.  I need to get my hands dirty with LINQ to SQL, it might be a nice alternative to CodeGen which I'm still a big fan of...stay tuned.

4) I attended a session on the Microsoft Sync Platform, very cool...kind of packages up a lot of nice features I built into a client application.  It was good verification that I got the architecture right!

5) There are some new additions to WF in 2008, specifically the ability to create WCF end points for sending and receiving messages.  I can't say I completely understand this yet, but there most certainly appears to be some interesting capabilities here.  There is also a project to embed a WF designer into client applications.  This could get very interesting.

6) It seemed like in a number of sessions I went to the presenters had one problem or another with their technologies, I guess this is probably a case of being on the tail end of the betas for Microsoft's latest releases.  I also give a few presentations on some of the latest cutting edge stuff and it makes me feel just a bit better that I'm not the only one that runs into some "technical challenges" doing demos.

In summary...another good conference, the next one will be in April in Orlando 

-ec

LINQ Thoughts

We'll it's been a long time since my last post, I've been extremely busy over the past few months, both working on The Chaos Filter as well as client work.  I have spent a bit of time on some new technologies that hopefully I'll get a little time to do some additional posts.  These include Silverlight, Microsoft Office Communications Server Speech Server, and learned a lot from Marshall Harrison of GotSpeech.NET fame.  I've also built a nifty little WCF service that does call backs to .NET clients, this could be very interesting.

Any way, I should probably get back on topic...it seems like everyone is going ga-ga for LINQ, yes, I agree this is a very cool technology, but I'm just not feeling the love from the perspective of providing a new set of capabilities we just didn't have before.  Maybe it's the type of systems I build that is prompting my skepticism.  Most of the systems I would consider are "transactional" or maybe stateless would be a better description.  This includes ASP.NET web page processing and other services oriented programming, basically take a bit of information do something with it (talk to the database, store a file transform it, cook it up in a pan) and send something back to the user.  That's not to say however that I'm not implementing an object oriented approach.  It's just there is a distinct start point, interaction with a whole bunch of objects to do "stuff" and a distinct end point and other than some very simple state and context information (usually stored in some sort of persistence storage such as a DB) I just don't keep state in memory between transactions.

Saying that, let's discuss a different class of application.  I'm currently re-inventing an IM server (OK, I got a good reason to do that, but that's not the point).  With this IM server, I'm using the WCF service as I mentioned above to make call backs to clients out in the cloud that have initiated a session (still need to understand the plumbing and underlying mechanism here, but again that's not the point).  So basically I have a service running in the background, clients connect and open a session, interact with that session and I can send call backs when invitations come in or send out a message to a conversation.  What this means is I'm creating almost an In Memory Data Store that contains relevant information to manage these sessions.  Basically right now, I've got everything working off of System.Collections.Generics.Dictionary objects where it's fairly simple to do a lookup to get basic state information for what I need.  Alright we are three paragraphs into this, I guess I should finally get back to LINQ and how it relates.  My in-memory database of state information is starting to get a bit more complicated and I would love a better way to do lookups against this database, I can see the value of LINQ in a BIG-WAY for this type of application, hopefully if you made it this far, you do to.  Unfortunately for this application it's a .NET 3.0 app, and I'm not ready to jump to .NET 3.5 to leverage this new technology.  So setting aside the using LINQ for relational DB access and the political debate that it brings, is this a valid use for LINQ in things that we just couldn't do before?  If so how many of us are writing these types of stateful applications of those of us that are writing these how many of these should actually be stateless and thus minimizing the impact that the new LINQ .NET 3.5 features provide?  I'm not proposing I have the answer here, but I'm posing the question...

-ec

Test Driven Development In the Real World

Well its been a couple years now and I've got enough experience doing TDD to feel that I can speak intelligent about what works (at least for me) using this development methodology.  I've seen some people say that they should never write a line of code before writing the tests, well that might be all-and-good for if your primary goal is to get an A on your test this semester, but in the real world, I'm not sure this is the best use of time.  Again, this is speaking from my past experience and the way I develop systems so your mileage may vary.

In my experience, as software developers we have to assume a certain level of stability in the building blocks we create.  Should we create test cases around our business objects that ensure when we execute a SQL Command against the database the SQL Connection object opens the connections and successfully executes the command? 

Let's look at the Red-Green refactor cycle.  At any one time when you are developing software you are attempting to solve a specific problem.  If you aren't sure of the problem you are trying to solve you might not be ready to start coding, it might be time to drop back to the white-board and draw some boxes/puffy clouds, or you may need to revisit your data model.  Either way just getting that little green light to come on within your screen may prove your current API is valid, but I'm guessing that, the API may change a little bit once you continue on in your efforts.

So if you made it this far, you have an open mind and we can continue our discussion...so let me say this, is there a place for TDD?  Abso-fricky-lutely I just did a little effort that was really built as more of a test concurrent type of development effort, but it's almost the same thing.  This was a very complex process where we had a disconnected database on a remote device that synchronized with a server.  We had to create some new "stuff' on the device that all needed to work locally before we could talk to the server.  No problem you say right?  Well where it gets interesting is the fact that the server uses integers to establish the relationships between the tables, that means if I create a new record on the device, I can't use an integer as the primary key, because that will only be available once we look at the identity column on the server database.  We need to build up all our referential integrity on the device database using Guido's then replicate those changes back to the server, create the "real records" send those "real records" back down to the device and make sure all our relationships are still happy.  For about the past year, I've been very happy using NUnit, however the client I'm building this for uses VSTFS so built the testing using this technology...really about the same thing, just slightly different syntax.  My new favorite little utility TestDriven.NET works like a charm with both.  So anyway, I was able to create some really nice scenarios that create the item on the device, add this to it, add that to it, change this, change that, then synchronize with the server and make sure the data I had on the device was the same as after I synchronize.

Another awesome experience I had with TDD was the development of a binary serialization algorithm for DataSets.  This I did as a pure TDD experience, I built my tests for the different data types I needed to serialize, then I created the methods and work on this until each of the unit tests passed.

My other experience wasn't so much with TDD but more of a formalized Unit Testing via NUnit.  I created a VB.NET ASP.NET 2.0 application, with about 150 unit tests, I'm not sure I gained a ton in development efficiency, however it did same my rear-end a couple times with my build cycle.  As part of the continuous integration environment that was in place for this project, we ran the unit tests, if they didn't succeed, we knew we shouldn't deploy.  Worked out slick and once the test were built it worked for "free" so that was kind of nice.

So what's my final opinion on TDD?   Well just as in anything moderation...and finding the right tool to solve the right problem.  I'm not convinced you need to write a test case to make sure the set and get properties work on your business objects, however if you have a complicated workflow, it is certainly worth the investment in time.

-ec

The Deadly Cycle or Keeping up with the Latest Technologies

As we progress through another year as Software Engineers, I'm starting to sense an alarming trend.  Please indulge me as I explain, if you are a software architect you are responsible for picking the right technologies to construct your system, to do this effectively you really need a fairly in-depth knowledge about the existing technologies or building blocks that are not only available today, but what is also available as either a CTP or beta release.  Now you pick the right technology and start constructing your system, let's say it's not a huge system, but it isn't trivial either, let's say you have a cycle time of 6 months.  As you build your system (and you picked the right technology) you will gain the experience necessary to master the technology, and if you planned it right and with a little luck, by the time you are ready to ship, they beta release you were working with go golden so you are set!

Now you are off to your next effort and design and build a project using your newly acquired expertise.  Another 6 month effort, great solution and everyone is happy.  What's happened in the past year?  Well, another new cycle of technology came out requiring even more detailed understanding.  This new technology may be so fundamentally different that your previous experience may now be obsolete.

Let's look at this another way, you know that about 1 year from now a fundamentally new technology is coming out, you need to build something, but you don't want build it off of a technology that will be obsolete when that technology so you hold off for the new technology.  Well your not shipping or even working on your product until you can get a stable CTP, even with that you run the risk of the API's changing by the time your technology goes live.  So you find the right time start constructing your system get a few months into it and -whammo- you see another technology that would be just perfect for your implementation that is really mutually exclusive to the technology you selected.  What do you do?  Just wait another 6 months for that technology to ship?  Probably not...

What are some things we can do to minimize the impact of new technologies?

Keep up with the absolute bleeding edge of technology.  There are many ways to do this.  In the past I only attended one professional conference a year.  Starting last year I attended two conferences www.medc2006.com and www.devconnections.com this year I'll be attending Dev Connections both in the spring and the fall, also MEDC 2007 and MIXX so this year it will be four conferences, with the incredible number of new technologies being release it really only seems like the best way.  With the new technologies coming out there are usually a number of important subjects within that technology.  These conferences aren't really a good way to get a mastery of the technology however it does give a good overview that will let you know the key parts.  These are also good for determining what is real and what isn't.  As to this point, there really isn't a substitute for experience.  How many times have you been to some sort of session or demo where they say "Build an enterprise site within 10 minutes with no lines of code"?  Well I've got news, as Frederick Brooks says in the Mythical Man Month, there's no silver bullet.

Another way that I think we can attempt to isolate ourselves from the rapid change in technology is to focus on the data.  Even if you choose to implement an SOA architecture (what ever you define that to be) when it comes down to it, at some point the rubber is going to meet the road, your going to need some objects with properties and method that actually does the work.  The way you factor these objects may be the biggest factor as to how well you can adopt the latest technology and put the latest and greatest user interface or offer the functionality provided in your objects as services.

Something that may be an option, but I haven't been able to practice is move away from coding.  Even though some people make it look easy building non-trivial software is hard and complex.  Things that look good at 50,000ft start to fall apart if you can't also understand how they work at the 1ft level.  How many times have you worked with the architects in the ivory towers that haven't coded in years and establish the all encompassing architecture that looks good on paper, but when you have to start building those objects with the properties and methods just falls apart or you create way too many lines of code.

On a final note, we need to start thinking about the software develop as business assets, not just lines of codes and assemblies.  What we develop should try to be at the right level of granularity for the task at hand.  If we build our projects where the majority of the business logic is in the UI, well we may have something we can sell and ship (which is by no means a bad thing) but we really don't have something that we can glue together using the latest technologies.

I'm sorry I just can offer any "silver-bullets" here but sometimes recognizing the problem is half the battle.  I think that we as software engineers need do the best we can to keep up with the latest technologies, invest a significant amount of time reading and researching new technologies and last an probably most important keep our customers and end users in mind.  If we do this things will just fall into place, our products will ship and we will start developing the goal of not just developing software assets, but business assets.

-ec

Another Strategy/Tactics Post

As I look over the last 6 years as a consultant, one thing becomes very clear, technical solutions by themselves will only get you so far.  As a great leader once said “ Good tactics can save even the worst strategy. Bad tactics will destroy even the best strategy” (George S. Patton) this is very true for software development, but with a slight twist.  As long as you continue an effective tactical operation, the problems with the strategy may remain hidden.

From 2001-2005 I developed a mission critical system for a very large company, over the course of these years, I did what it took (including searching out Internet café’s in Key West) to keep this system operating as efficiently as possible.  As an outside technical development asset, my primary mission was make sure I kept the business constituents happy, the scope of the change I could affect on the organization was limited, for long term, this change would be required to embrace and support system.  As I left this engagement in early 2006, it was clear that this system was not going to be properly supported.  In March of 2007 for better or worse, Software Logistics was re-engaged on this effort and will make a significant positive impact.

So how does this come back to my original quote from GSP?  In this effort I worked on the “Product” and very little on the “Process”.  The product succeeded at the tactical level with assistance of Internet cafés in Key West, however at the strategic level the proper systems and protocols where not being put in place.  It was clear the technical/tactical part of the solution was sound however the strategic part needed some help.   What was required for long term success on this project was a complementary skill set.  Enter my business partner David E. McCracken , I’m extremely excited to work with Dave on this project going forward.   There is a considerable amount of power and flexibility within the system that was developed however this power and flexibility came at a cost of an investment in understanding two domains, the first being a non-trivial understanding of the subject matter data and the second being an understanding of the architecture.  The adoption beyond the immediate team required considerable effort that in some way is mutually exclusive to the day-to-day activities.    This effort is not in creating the code, stored procedures or even the documentation around these software artifacts.  This effort is in making sure that our tactical efforts that we perform as software engineers today not only satisfy the immediate and pressing needs of the business, but also are done is such a way that they can be repeated on a consistent and predictable fashion in to support strategic goals.  In the short term tactics can make up for poor strategics, however in the long run this is not a sustainable model.  Some great gems of knowledge can be found on David's blog on some ideas on how these efforts can take place.

Bottom line is how much are you working to satisfy your business constituent's tactical and immediate needs and how many fail-safes do you have in place to ensure the long term strategic organizational goals?  Do you have the right infrastructure in place for both these equally important journeys?

-ec

DevConnection Orlando 2007 - Day 1

I was up in the air as to going to DevConnections earlier this March, but after making the decision and attending Day 1, I'm extremely glad I showed up.

It's not a destination, it's the journey

While trying to implement a Project Delivery Optimization initiative, it's not the destination it's the journey.  Where you want to get to has a lot to do with where you are.  As you set off on the road to "make-things-better" when delivering software you need to look for the right steps to make increment improvements today without limiting your options in the future.  The processes and tool you need to take you to the next level will serve as a set of building blocks for the level after that.  There is nothing wrong with incremental gains, however as you decide on a process, tool or technology, you should have an understanding of what their limits are what can be done when you hit those limits.  For any non-trivial development organization as you achieve your goals, one of the biggest changes you will make will be to the culture of the organization.  As you make these changes, you will establish momentum.  If a certain process you start has limits that will only take you so far, you don't want to lose all that momentum.

Let's say you establish a project specific initiative, you see progress beyond what you expect.  The tools and processes you come up with  work like clockwork on that initiative.  You want to repeat that on another project so you implement that initiative on the next project.  Now you have a couple/few projects working like a well oiled machine.  You decide to implement that for the other 12 projects in your area.  You do this, however you see that things are starting to slip and you aren't seeing the improvements in efficiencies you expect.  What happened?  Maybe the initiative you implemented works well at the tactical project level but not at the strategic organizational level.  The way this initiative/tools work doesn't take into account any additional commitments beyond the project level and there is no way to change that.  You've made gains but now you are at a dead end and changing course could mean starting from scratch.  If you start out with the strategic end in mind and keep that in mind while making tactical maneuvers your journey toward the utopia of project delivery execution will be much smoother!

Have you ever made any decisions that where absolutely the right decision at the time, however as time went on you find that the investment you made in that decision limited any possibility for future growth without significant pain?

-ec

Developer Efficiency

At the very essence of what we do as technical developer folk is take the needs of our business stake holders and turn those into 1's and 0's (and maybe in our lifetime we might figure out how to get 2 ;-) ) that business stake holder can run as software on our computers.  Any thing else is pure rubbish! 

So what are the attributes of an efficient coder?

Technical Aptitude

This is a baseline of becoming an efficient coder, when it's all said and done you must have a certain level of Technical Aptitude, that's not to say you need to be a "Rocket Scientist" however you should have certain skill such as problem solving, a general nature to ask "hmmm...I wonder how that actually works?" or "boy that sure is some cool technology, I wonder if I could build that?".  I think this is something you either have or you don't.  Not having it is not a bad thing it just means this type of work may not be a good fit.  I know any time I try to do something creative with any sort of graphics problem, I can spend 3-4 hours on trying new things and in the end it probably looks worse that when I started.  This isn't a bad thing, but the sooner you can recognize your weaknesses, the sooner you can find other people around that complement your strengths that make up for those weaknesses.

Memory

As a developer there are just too many different technologies that could be implemented to solve a problem, too many Languages and API's to learn, too many object models, too many command prompt arguments and keywords, you get the idea.  The more of these you can stash away and bring to the fore-front when necessary the quicker you can continue developing and not doing discovery.

Perceptiveness

Being able to read between the lines and think to a long term strategy is important when developing your solutions.  I see Software Development as chess match.  At any given time you are presented with a certain set of facts or knowledge, each time you sit down to design/code the moves you make have a major impact in how the pieces get moved and sets you up for your next designing/coding session.  I've just seen too many software efforts take the fundamentally wrong approach early on, and those projects never really recover.  Although an extreme example, let's say you wanted to write a simple contact manager, do you think you would start writing this in Assembler?  How about some sort of auditing function where a copy of all items was made into a database every 15 minutes, then a process was run to detect and report on changes, this was a real world scenario where a developer worked on getting this process working for about four weeks, and never did...the efficient coder made the correct chess moves and had implemented in an afternoon.  I see this is a very common problem in software development.  Do you start coding before you have a true understanding of the problem you are trying to solve?

Attention to Detail

This is a really hard one for me, coming up with creative solutions and looking at the big picture sometimes blurs some of the details.  What's interesting is that when I'm doing low-level programming such as embedded systems development, my eye for detail is very sharp...go figure...to be a efficient coder means developing system with little or no bugs.  The challenge here is that if you pay too much attention to the details, you may loose site of the big picture.  Coding something that implements the fundamentally wrong solution even if perfect and bug free is worth little to no value.  I think this is one of the bigger areas where we can use technologies, tool and processes to improve our efficiency.  After all computers aren't very good at creativity however they are extremely good at the details.

Experience Level

I think by far the biggest impact on this ratio is the experience of the person doing the development.  This experience is not just in the actual programming languages such as Java, C, C++, or the Software Development Life Cycle/methodologies, but to an even greater extent programming a wide variety of business processes.  Just as with software, certain things can be "abstracted" the same is true with business processes.  This experience also helps facilitate the conversations with the business stake holders, the more you understand about business in general, the more time you can more quickly get to the specifics of what makes this problem unique. 

Experience only comes with time.  You can do certain things that may not seem that important, but really are.  There is no substitute for spending time with the business stake holders even is you just sit in the room and not contribute anything.  That is not to say they should have a direct line or to influence your day-to-day scheduling.  But as a manager early on, I used any possible opportunity to get the developers in a room with the stake holder.  When doing embedded systems work it was always a good reminder going to the field and realizing that in the real world when my software is working it's not just a little LED that comes on at the right time but it's actually a 20 ton rock crusher that would be very bad if it came on at the wrong time.  It puts everything you do in a different perspective.  How often do you have actual conversations with your business stake holders?

Passion

What really differentiates you as an "efficient coder"?  Do you really just plain and simple love what you do?  Or are you just coding to pick up a paycheck?  Life is just too short to spend the majority of it working in a job just to pickup a paycheck.  If at a certain extent you have qualities mentioned above and your are passionate about taking the needs of the business stake holders and turning them into the 1's and 0's in exactly the right order as efficiently as possible (what ever that means on your particular effort) the chances of you being an "efficient coder" are pretty good!

Are you an "efficient coder"?

- ec

Custom WebParts in SharePoint 2007

Creating a custom WebPart in SharePoint 2007 isn't all that terribly difficult, just a few basic steps that may not be completely obvious...in addition if you want to deploy your WebPart on SP 2007 it may contain some additional resources such as gif's or java scripts.  Wouldn't it be nice if you could just deploy one assembly with everything you need?  Well that's possible so let's do that as well...

1. To start out, just create a new VS.NET 2005 class library project and add a reference to "System.Web".
2. Go ahead and setup a reasonable sounding Assembly Name and Default NameSpace, these will be important when registering your component with Share Point 2007.
3. While your are changing your project settings, find the Signing Tab and make sure "Sign the assembly" is checked.  You will then need to go ahead and create a new KeyFile.  So far straight forward right?
4. Now let's add our web part, to do this simply add an class to your project.
5. The code in your web part should look something like Not a example of good coding but that isn't the point ;-):

         da.Fill(tblTime);
         grdTime.DataSource = tblTime;
         grdTime.DataBind();

         Controls.Add(img);
         Controls.Add( new LiteralControl ( "<br/>" ));
         Controls.Add(grdTime);

         base .CreateChildControls();
      }

      protected override void Render( HtmlTextWriter writer)
      {
         writer.Write( "<h4>Hello World!</h4>" );
          base .Render(writer);
      }
   }
}

Before installing this to SharePoint 2007, let's complete this section by talking about what we need to do to embed the resources with the assembly.

1. Create an Image directory within your project and copy the Image there:
   
2. You can see that the name including the NameSpace is "SoftwareLogistics.SharePointTest.Images.Target.gif" (Case is important here)
3. Once you copied the image there you need to make sure you click on "Properties" and then set the Build Action to "Embedded Resource" for Target.gif, very important to do this...
4. Now open up your "AssemblyInfo.cs" file that is in the Properties folder of your project.  Add a line to it similar to
   [assembly: WebResource("SoftwareLogistics.SharePointTest.Images.Target.gif","image/gif")

5. You will also need to add using System.Web.UI; to the top of your AssemblyInfo.cs.

6. Finally in the code you can set the url of the image as:
   img.ImageUrl = Page.ClientScript.GetWebResourceUrl(this.GetType(), "SoftwareLogistics.SharePointTest.Images.Target.gif");

Now your assembly is ready to go all you need to do is turn that into and assembly and your are ready to incorporate it into your SharePoint 2007 site, you can even us this as a WebPart or even a standard Server Control on any ASP.NET 2.0 site.

To install the the component on the SharePoint2007 server you need to do the next couple of steps...

1. First we need to get our component into the GAC so just drag it into the file pane for Windows\Assembly, you can see the my file here:
   
2. Make a note of the Public Key Token, you will need that to register your part with SharePoint, you can also right mouse click on the assembly click on Properties and copy the Pulbic Key Token from there.
3. The final step to make it appear as a "potential" web part within SharePoint is to register the component in the Web.Config file.  So find Web.Config for the SharePoint instance you want this work with and open it in your favorite XML editor.
4. Find the section labeled "SafeControls" and add the following line (you can always just copy one of the existing lines and fill in your information.
    <SafeControl Assembly="SoftwareLogistics.SharePointTest, Version=1.1.0.0, Culture=neutral, PublicKeyToken=8220d66cd77f3b8d" Namespace="SoftwareLogistics.SharePointTest" TypeName="*" Safe="True" />

At this point SharePoint knows about your WebPart, but you'll need to make it part of the Gallery so open up your SharePoint site and do these final steps

1. Click on "Site Actions" and then "Site Settings"
2. Within the "Galleries" section click on "Web Parts"
3. Click on New, if all went well you should see the part you created within the list, if you don't see it there, go ahead and reset IIS.
4. Put a check mark next to your new web part and then click the "Populate Gallery" button.

At this point your web part is ready to be included just like any other WebPart.

Happy Coding!

- ec

SharePoint 2007 - It's finally all coming together!

I remember in the very early days of .NET they had a cool demo of how to build a portal in ASP.NET, this was called "I Buy Spy" from what I understood went on to be DOTNETNUKE, I was excited about the concept of configurable content within the portal, it had all the right concepts, adding tabs, little widgets you could configure etc... These were really just Web Controls (ASCX) or Server Controls (compiled DLL's).  My third version of "The Chaos Filter" used this concept extensively. 

Then with ASP.NET 2.0, they introduced the concept of WebParts, this was nice however you had to build up a set of scaffolding and use the provider model to use these within your site (at least as pure web parts).  Not terribly difficult but it limited your deployed options.  At the time SharePoint 2003 had something called "WebParts" as well, extremely similar in both appearance and function, however these "WebParts" were not the same thing as those created with ASP.NET 2.0.  Very disappointing (and confusing), SharePoint 2003 web parts actually came out first, and I assume that Microsoft kept the name since it seems to fit this concept so well and the intent with ASP.NET 2.0 web parts was that they would work with SharePoint 2007.

Version 3.0 of the product really defined and flushed out the data model and workflow engine however, I just wasn't very happy with the presentation layer in ASP.NET 1.1 using the ASCX's and custom controls.  With the introduction of the ASP.NET 2.0 I started on version 4.0 of "The Chaos Filter", this time I focused on an architecture that was built from the ground-up to use web parts and leverage the existing data model and workflow concepts that make the Chaos Filter unique.  This architecture relied heavily on code generation from a product called CodeSmith, templates where created to not only create a simple DAL that mapped to tables in the database, but it also created two web parts (master/detail) for each tables.  This obviously doesn't mean that you can generate 100% of the application, however it does mean that it can very rapidly give you web parts that work out-of-the box that you can customize.  Anytime I hear "You can build your hole site in just three lines of code" my spider senses tell me to watch out!  This solution is really intended to put in place the framework and plumbing that you can open up in your development environment and make it do something useful.

So here we are, SharePoint 2007 was released last November, what does this give us that we really didn't have before?  We now have the ability to easily create little "chunks" of functionality in the form of "WebParts" that can be wired up to create applications.  So with the data model defined in V3.0 of my product, the architecture to include code generation defined in V4.0 of my product, and a mature framework in SharePoint 2007, it's time to start figuring out how to package these concepts into something that will provide value.

-ec

Does this only happen to me?

I've been cruising along on all eight cylinders, making sure and steady progress on a chunk of code.  I get to the point where I think I've got all the problems solved and want to integrate a bunch of things together and whammo - I get a flat tire...something stupid like my VPN drops, a real slooooowww connection speed where it's painful to do anything or maybe a reference to some library "just" disappears, or my favorite something like "Internal Compiler Error please start Visual Studio".  Just as I was ready to pull all the "stuff" together on a project I'm working on today that "flat tire" was all of a sudden my clip board in Vista stopped working...very odd...very frustrating...real momentum killer...

-ec

Filtering a SQL Server Table by content of XML

One of my applications parses custom forms from a web site that are defined by an end user, it then stores the actual content of the form as an XML document in a SQL 2005 database.  I recently had the need to write some queries to identify specific records in this table based upon content entered on the form.  To do this I needed a "where" clause that would filter the the records based upon the content of the XML.  The following solution seems to do the trick:

select FormId
  from MyForms
where FormType =  'MyNewForm'
   and FormXml . value ( 'if( /root/Field1=200 eq true() ) then 1 else 0 ' , 'bit' ) = 1
   and FormXml . value ( 'if( /root/Field2=300 eq true() ) then 1 else 0 ' , 'bit' ) = 1
   and FormXml . value ( 'if( /root/Field3=500 eq true() ) then 1 else 0 ' , 'bit' ) = 1

Since our filter arguments (200,300,500) are really passed into and built as part of the string we really can't use a parameterized query, but I think that is probably OK.  Since the initial output of the XQuery is XML, we need to convert that to a "bit" field that we can then use to complete our Where Clause

 -ec

Back in Business Again (4 monitor configuration on Vista)

Over the past year, I've really been addicted to using my four monitor configuration within Windows XP.  In October, I made the switch to Vista for my main desktop system and have had a difficulty running in this configuration.  First with a couple of ATI X1300 cards, where when I go into 4 monitor mode, one of the screens was half black half green (with RC2, but not fixed in RTM Vista) Then I purchased a couple of NVidia cards, a 7900GS PCI Express card, and an FX 5200 PCI card, I was able to get these working, however I wasn't able to rotate the screen into portrait mode, which is really almost a requirement unless you want to constantly be tweaking your neck to view all the monitors.  The native drivers for NVidia (at least version 9.6.8.5 dated 10/9/2006) did not support any mechanism for doing rotation so I found this very kewl program called iRotate from an excellent company EnTech Taiwan. The following post describes how to tweak your registry to allow for iRotate to work with the NVidia driver.  They have another very cool program called PowerStrip that allows you to do some pretty amazing things with your video card.

Here's a picture of my development workstation...

The most important part of this setup is just to the left of my keyboard (coffee mug).

I think that 4 monitors is actually an excellent environment for doing development, let me explain my setup

From left to right:
1) 900x1440 Monitor - This is really my system dash board, I run Outlook, keep my IM window open, SysInternals (or I guess Microsoft's) Process Explorer and while really "getting into it" I may start an instance of DebugView or CEDebug view on top of those windows.

2) 900x1440 Monitor - Tool windows for VS.NET, I usually have the following configuration, the screen divided from left to right in about 2/3 on the left and 1/3 on the right, the left side is divided just about in 1/2 with the top having the Output and Error List window, the bottom has properties and a couple of cool VS.NET addins I created using the DevExpress DXCore product (if you have any interest in building add-ins for VS.NET you MUST look at this Free, yes I said Free product, it takes care of all the plumbing so you can focus on your task at hand), one addin allows me to bill time and the other has a bunch of metrics like how much time I've spent on classes, methods, billed against clients as well as the number of builds I've performed.  The right side of the screen has my solution explorer from the top to bottom so I can quickly open files.  In my attempt to free myself from using the mouse, I've started to use hot keys to open files, but the jury is still out on if this is more efficient than just using the mouse.  In addition there is a tab on the right side that allows for access to the Team Foundation Server explorer.

3) 1200x1600 Monitor - This is where the "magic" happens, this is my current port between me and the computer for translating the designs I got from my brain into what ever language I'm using (mostly C#)...still think there is a better way to do this, but that's another post for another day...

4) 1200x1600 Monitor - Work space, this is where I test the application I'm working on, open up IE windows, open up file explorer etc..

The idea with this configuration is really to allow for very efficient context switching, it's much easier to turn my head, then open a window, check it out and get back to my main task

Other "stuff" in the pictures:

I just love my Microsoft Natural Ergonomic Keyboard 4000, it took a little while to get used to but I started without the detachable support on the front that raises the front up about 2" and moved to that after about a week.  I wish it was wireless and had a finger print reader built it, but I've got two of these and feel that I'm at a disadvantage when I can use it.  This is really a good tool to increase the "TX Baud Rate" between the brain and the computer.

I'm impressed with the Logitech mouse line, I had one of the rechargeable ones, but many a time I've been feverously working on a project, the low battery light came on and I didn't have time to recharge before it went dead.  I'm currently using the Logitech MX610 Laser Cordless mouse and like it.  It has a number of feature I don't use, but I like the way if fits in my palm and the battery life is excellent (besides when the battery gets low I just need to grab a couple AA's from my battery drawer and I can continue on with life (instead of get my old corded mouse out while my other one recharges).

PDA Collection

My old workhorse (very powerful processor & lots or memory) the HP iPAQ hx2750

My current phone (jury is still out on this one) the Motorola Q (Smart phone not Pocket PC phone)

And finally my i-mate JasJar, I like this device, in my line of work (not a mobile user) it just isn't a good fit.  I use this for testing VGA resolution applications on mobile devices.

And finally you can see my tablet PC hp TC1100 to the right of the monitors in the first pix, I love this tablet, it's a pure tablet, not a laptop wannabee/tablet wannabee, when I want a laptop, I'm usually using it for something completely different than when I want my tablet.  To my wifes joy, I think I'm going to be upgrading to a UMPC as soon as the right one comes out and she get's the coveted tablet.

- ec

Flexible Systems Integration Architecture

I may have a couple of large projects next year where I need to build up a great deal of functionality that easily needs to be integrated with existing systems.  What we want is some sort of clean very usable portal concept where a user can work with a predefined set of business objects.  The idea here is not to create some sort of "holy-grail" of a development environment where a business analyst can sit down and drag a few objects on to a page and wire them up.  So now that we took the whole "build a system without one line of code" marketing statement out of our vocabulary we can safely say we do need to write code and figure out the best way to do this to:

1. Get a high-level of reuse among different implementations
2. Do programming at the right level to minimize defects tedious coding
3. React to changes very quickly
4. Provide a clear upgrade path
   

First let's define the three aspect that are present in pretty much every system we are going to build, probably in the order of importance and from the most static to the most dynamic:

Data - In each problem domain there are a core set of data that describe the "world" of the domain.  For a sales system, this is going to be something like Customers, Products, Sales People, Sales Orders, Invoices etc...each of these has their unique set of attributes that describe them.  I would venture to say that in most sales system you are going to have at a minimum the above set of objects with probably 85% of the attributes on those objects remaining consistent.  For these type of objects the definition of these attributes probably remains fairly constant with respect to time.  That is to say the description of the objects is probably the most "static" part of your system.  I guess this is pretty much the premise of OO.

Business Rules - Objects by them selves might be interesting however to do anything with them you need to implement some sort of business logic, something like a sales person "CREATES" the order etc...these are really the functional requirements of your system.  In our sales system, although the objects and their attributes are probably about 85% the same across different systems, the actual functional requirements and business rules are probably much less consistent.

User Interface - Well now we have our data in our objects and we have methods so we can make them do something interesting, unless we are building a batch processing system, we need some sort of user interface.  If we look at this in terms of our sales system, there are really three components of our User Interface: 1) Simple CRUD stuff (Create Read Update Delete) 2) The buttons you press to make it do something like create a new order 3) Work flow.  The first two items are really pretty basic, get data from the business object display it on the screen, validate it and dump it back to the biz object as well as react to a button to launch a screen.  The third item is what really differentiates one system from the next, the work flow that's wires up the user interface to the business rules.

Let's talk a little bit about some concepts to solve these problems with a high-level of reuse and integration into back end systems.

Data - As we defined above, we will want to create some sort of rich object model based upon the domains we are building the system for, these should contain the attributes the core attributes that we defined above that are similar between different implementations.  These objects would then in turn be "bound" to the underlying data objects to provide the basic CRUD functionality.  This would either be through the use of implementing interface contracts in a high-level language or creating stored procedures in the underlying database that would bind our objects to the data.  We might implement our Customer object to execute a stored procedure on an Oracle database and return some sort of result set for one implementation and write code to execute a Web Service method call to retrieve the customers attributes in another, either way we let the specific implementation provide the data and bind it to the attributes on the business object.  Our objects would also need to provide some sort of mechanisms return lists and collections that are implemented based upon the data assets within the organization.  The idea here is the business object in our object model provides a well defined set of services to the work flow and user interface layers, but the actual persistence of the data will be implementation specific.

Business Rules - OK now we have a way to load and persists business objects as well as return collections and lists of these.  Now we need to make them do something.  The "do-something" part really comes in two flavors, simple methods we can invoke to set status and send out notifications to more complex work flow with respect to time.  They are tied together, but it may help to think of them separately.  As with our data implementation, our core implementation needs to provide a key set of methods that do certain things, like create a new order, send an email etc...these should be customizable by inheriting form base class and overriding methods.  The next flavor having to do with behavior of the object over time is really considered work flow and this probably the area where now two systems will be a like.  I think the right way to do this is through some sort of Work Flow engine and it just so happens with .NET 3.0 Microsoft released one.  The exciting part of this (at least as far as I understand it so far) we should be able to create our objects that have our properties and methods, but then "wire" them up using XAML to make them behave in a custom way.  This is not say we can build our systems without writing any code, but it does mean we may be able to "wire-up" our apps to get 80% of the way there, and then be very flexible with respect to change over time.

User Interface - I believe that some sort of portal concept is the right way to go here, I'm very intrigued by Share Point Portal Services 7.0 as providing the plumbing to hold everything.  This area probably will require the most customization however this will probably just be starting out with some control templates, dragging a few additional controls on to the template then wiring those controls up to the business objects.  The portal "needs" to be built as a set of building blocks that can be assembled and "connected" at run time.  I think the right way to do this is through the use of Web Parts in ASP.NET 2.0.  In addition, it will be important to create some sort of role based security that controls access to the UI components/data not only to show/hide features and UI components, but also something to secure access to either groups of records or specific records.  It's also important to build and integration story that will leverage any existing credentials that the company may already have.  I would love to see the use of "Card Spaces" for this, but I'm not sure that's all that good of an idea.  This may however be on implementation of our security model.

More to come on this topic...I'm just starting to get my head into these efforts....

- ec

Correct Architecture Level is a Formula of...

Software Engineering with WorkFlow

What is the one thing we know for certain when we start ANY software development effort?  It really will never be 100% complete...the functionality provided by the application will be a function of changes and time.  What else do we know of a well thought system?  The core objects of the domain and their attributes are fairly static, the actions that can be taken on them can be fairly well defined and once they are defined, the may change slightly but remail fairly constant.  This is the basic premis of OO, it's been a long time since my last conversation of OOA Object Oriented Analysis, OOP Object Oriented Programming and OOD Object Oriented Design.

So if these concepts are fairly static, what do we mean that any real software solutions functionality will be a function of change and time?  These changes are mainly a function of how these attributes and actions are assembled and their service are presented to end user (or external systems).

What do programmers know how to do (at least experience ones)?  Take the intent from the subject matter expert and convert that into 1's and 0's with the help of developer tools (maybe someday we'll actually get a 2 or 1.5 if we get our shtick together).  Once us coders build those little objects how can we translate/assemble those into something that actually provides something useful?   The answer is WorkFlow(let's assume for now we can bind some sort of UI on the functionality).  I believe we are getting to the point with technology where we can expose the design of this workflow to the subject matter expert; or at least a fairly technical one. 

I believe the concept here is to leverage the concept of finite state machine, along with work flow id and objects or object heirarchies that know how to serilize and deserialize themselves.  These state machines must be able to accept events from many different external sources, including a user interface, time events and web services.

Stay tuned for future posts on some ideas on how to empower the subject matter experts to maintain workflow.

-ec