October 28, 2016 at 1:03 pm
aaron.reese (10/28/2016)
With CF you can rapidly prototype based on the business problem and then retro-fit the underlying data structure without having to touch the business logic or the entity classes.
Business logic should drive the initial design of the database as well as any over lying structure and both should be designed to work together, neither should require retro fits outside of business changes because of one or the other being designed poorly and being completely inflexible.
October 30, 2016 at 7:31 am
Agreed. but when you are prototyping it is very likely that you don't have the full story from the business, especially where they need to persist changes in entities which means that the initial design of both the business logic and the supporting database is incorrect from the start. The problem here is not in the prototyping concept but in management's inability to understand that the prototype is just that and should be discarded when then building for release.
October 30, 2016 at 8:32 am
aaron.reese (10/30/2016)
Agreed. but when you are prototyping it is very likely that you don't have the full story from the business, especially where they need to persist changes in entities which means that the initial design of both the business logic and the supporting database is incorrect from the start. The problem here is not in the prototyping concept but in management's inability to understand that the prototype is just that and should be discarded when then building for release.
I've found that a whole lot of very well meaning people have simply forgotten some of the basic tools to correctly identify "Business Logic" in a language that is both simple for both sides of the house to understand each other during the prototyping and development processes and accurate enough to design entities and sometimes even write code from.
One of those tools is a "Process Flow Chart". No prototype should have even a single character of code written without one. Think of it as a sort of work-breakdown-structure. I use them even on relatively short/easy projects. Not only do I keep them up to date, I color code them to easily see what is being worked on, what is complete, and which items have showstoppers that need to be solved before the logical block and those that follow can be solved. It provides an instant status of the big picture and a road map of what needs to be done and even who needs to do it.
Although there's no citation that he ever said such a thing, Albert Einstein is frequently {mis}quoted as saying something that gets to the heart of the matter when designing and building Business Logic, applications, and databases...
"If you can't explain it simply, you don't understand it well enough."
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2016 at 7:48 am
Jeff Moden (10/30/2016)
aaron.reese (10/30/2016)
Agreed. but when you are prototyping it is very likely that you don't have the full story from the business, especially where they need to persist changes in entities which means that the initial design of both the business logic and the supporting database is incorrect from the start. The problem here is not in the prototyping concept but in management's inability to understand that the prototype is just that and should be discarded when then building for release.I've found that a whole lot of very well meaning people have simply forgotten some of the basic tools to correctly identify "Business Logic" in a language that is both simple for both sides of the house to understand each other during the prototyping and development processes and accurate enough to design entities and sometimes even write code from.
One of those tools is a "Process Flow Chart". No prototype should have even a single character of code written without one. Think of it as a sort of work-breakdown-structure. I use them even on relatively short/easy projects. Not only do I keep them up to date, I color code them to easily see what is being worked on, what is complete, and which items have showstoppers that need to be solved before the logical block and those that follow can be solved. It provides an instant status of the big picture and a road map of what needs to be done and even who needs to do it.
Although there's no citation that he ever said such a thing, Albert Einstein is frequently {mis}quoted as saying something that gets to the heart of the matter when designing and building Business Logic, applications, and databases...
"If you can't explain it simply, you don't understand it well enough."
Hey Jeff, what tool(s) are you using for the Process Flow Chart. I remember learning and using those types of design diagrams in college and liking the clarity it gave me, but I haven't found a tool that I like using yet. IIRC in college, they ended up being mostly hand drawn.
October 31, 2016 at 7:51 am
LightVader (10/31/2016)
Jeff Moden (10/30/2016)
aaron.reese (10/30/2016)
Agreed. but when you are prototyping it is very likely that you don't have the full story from the business, especially where they need to persist changes in entities which means that the initial design of both the business logic and the supporting database is incorrect from the start. The problem here is not in the prototyping concept but in management's inability to understand that the prototype is just that and should be discarded when then building for release.I've found that a whole lot of very well meaning people have simply forgotten some of the basic tools to correctly identify "Business Logic" in a language that is both simple for both sides of the house to understand each other during the prototyping and development processes and accurate enough to design entities and sometimes even write code from.
One of those tools is a "Process Flow Chart". No prototype should have even a single character of code written without one. Think of it as a sort of work-breakdown-structure. I use them even on relatively short/easy projects. Not only do I keep them up to date, I color code them to easily see what is being worked on, what is complete, and which items have showstoppers that need to be solved before the logical block and those that follow can be solved. It provides an instant status of the big picture and a road map of what needs to be done and even who needs to do it.
Although there's no citation that he ever said such a thing, Albert Einstein is frequently {mis}quoted as saying something that gets to the heart of the matter when designing and building Business Logic, applications, and databases...
"If you can't explain it simply, you don't understand it well enough."
Hey Jeff, what tool(s) are you using for the Process Flow Chart. I remember learning and using those types of design diagrams in college and liking the clarity it gave me, but I haven't found a tool that I like using yet. IIRC in college, they ended up being mostly hand drawn.
We typically use Visio. for simple flows, Power Point has enough shapes to get you going.
October 31, 2016 at 8:11 am
Ross McMicken (10/31/2016)
LightVader (10/31/2016)
Jeff Moden (10/30/2016)
aaron.reese (10/30/2016)
Agreed. but when you are prototyping it is very likely that you don't have the full story from the business, especially where they need to persist changes in entities which means that the initial design of both the business logic and the supporting database is incorrect from the start. The problem here is not in the prototyping concept but in management's inability to understand that the prototype is just that and should be discarded when then building for release.I've found that a whole lot of very well meaning people have simply forgotten some of the basic tools to correctly identify "Business Logic" in a language that is both simple for both sides of the house to understand each other during the prototyping and development processes and accurate enough to design entities and sometimes even write code from.
One of those tools is a "Process Flow Chart". No prototype should have even a single character of code written without one. Think of it as a sort of work-breakdown-structure. I use them even on relatively short/easy projects. Not only do I keep them up to date, I color code them to easily see what is being worked on, what is complete, and which items have showstoppers that need to be solved before the logical block and those that follow can be solved. It provides an instant status of the big picture and a road map of what needs to be done and even who needs to do it.
Although there's no citation that he ever said such a thing, Albert Einstein is frequently {mis}quoted as saying something that gets to the heart of the matter when designing and building Business Logic, applications, and databases...
"If you can't explain it simply, you don't understand it well enough."
Hey Jeff, what tool(s) are you using for the Process Flow Chart. I remember learning and using those types of design diagrams in college and liking the clarity it gave me, but I haven't found a tool that I like using yet. IIRC in college, they ended up being mostly hand drawn.
We typically use Visio. for simple flows, Power Point has enough shapes to get you going.
I typically use Visio mostly because the connectors and large annotated arrows are easy to use and control the size of. It's also easy to make a "monster" chart that I can print on a continuous-sheet plotter if needed as wall paper in a project war-room. It's also pretty easy to convert to sectional Word documents.
I can't remember what it was called but there's a shareware version of a product that does similar to what Visio does for such things without all the deep stuff that you don't normally use in Visio. I think the name had the word "FlowChart" in it but don't remember for sure because I've always had access to Visio for such things.
The PowerPoint method is ok but is a bit more tricky with connectors and alignment especially if you need to make something fairly large and suffers a fair number of changes as what normally occurs at the beginning of a project (can't correct a blank piece of paper :-P).
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply