Some math could be said to be derived from such things as databases, security, chickens, and eggs and their prioritization.

But really, cryptic ramblings aside.  What are really the first things that need done on a software project.  There is the architecture which of course needs done, but before that, pieces need in place.  One piece of information that obviously needs to go first is some idea that a business process exists and needs modeled.  A business process also being a "need" or whatever one wants to call it.  But even BEFORE the needs of the business process are conerned one needs to consider one thing that is even more important to the business.

The security of the business, the roles of users within that security context, and how these things need broken down into logical units of organization.  If a business really doesn't care and does not want security then great, just pass on the whole notion.

Security is so key though, that if held off until after the coding starts then there will be massive costs in time and effort along with cold hard cash in paying to get it fixed.  Waiting to fix security post project start is far worse than any other aspect of an application having scope creep within a domain.  The multiple in time consumed is massive.

So the next time one is on a project that doesn't have the security model fleshed out, but is discussing "we'll do it after the fact", make changes immediately, be ready for a long battle, or leave.  Generally speaking it isn't worth the fight later on, being that one might as well just re-write the entire application.

Ok, so I don't really have THAT many projects.  But sometimes it seems that way.  Soon I'll be starting on the second phase of my personal "Travel Tracker" application sets.  Currently I have the web application completed (with no where to host it currently, community server which this blog utilizes kinda kills any other web apps via an HTTP Handler or something, maybe I can pickup the SDK and add to it, but for now I'm not going that route), the core of the Smart Client Software Factory pattern Web Application created, and am working on a basic Windows Application.  When all three of those are complete (at least the Web and regular Windows Apps) I'm going to start working on path finding and travel tracking of vehicles via dedicated and non-dedicated routes (i.e. open space path finding & rail/road track path finding).  My research begins today for this project and looks like it could be monstrous in size and intensely interesting.

In the next 3-4 weeks I will have a zip of the project files for the Web & Windows Applications hosted on the root domain file shares (http://adronbhall.com/files/default.aspx)

So recently I've had a gluttony of technology writing laziness!  I've been working on and off for about 2 weeks on part 3 of the CAB & SCSF tutorial.  Eventually I'll sit down and get going with that again so I can get it produced, shiny, and posted.

In the interim I also am putting forth efforts for other various design pattern, software architecture, database, business intelligence, and related how to entries.  I also in the near future intend to start producing these documents in Word, PDF, and other formats to provide for easier print out for reading, teaching, or other needs.

One of my other entry categories that I promise I'll get posted up here soon is the additional application designs and builds that I'm putting together.  Currently I'm working on the simple Travel Tracker Application, which is what the CAB & SCSF Tutorials are based on, but soon there after I intend to start several new projects, some web based, some "possibly" CAB based or Windows Application based, and most certainly whatever Microsoft actually puts together for their XAML based products.  At some point if they pull that off I'm sure I'll end up with a whole bunch of XAML based applications.  But for now...

...stay tuned and I'll get these entries going soon.

So once again I'm back at putting together management methodology for MVP designs.  It seems also pertinent that sometimes, against what would seem logical, it's also a good idea ot mix MVP and MVC design.  With the possiblities for using controllers for business flow when writing the business flow in presenters breaks apart the logic into too many seperate and sometimes disparate locations.

The idea here is a wizard with multiple screens, each being a SmartPart, that is then fed into a TabWorkspace or other multiple smart part container, should utilize a singe controller for the basic business logic flow, while the presenters can or should hold individual screen business logic.  Also of course linked up to any pertinent business rules validation and other such infrastructure.  Often times one or the other is used (I say often times, MVP and MVC aren't exactly regularly used design patterns) and mixing seems like it might be "against the rules".

Contrary to that one should utilize such break downs with prudent and thought out design of the controlers and presenters.  With careful design developers can then develop within their particular business or infrastructure scope without infringing upon each other's efforts.