Greenfield Software Design
-
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development". I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality. I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.) I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project. So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
-
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development". I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality. I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.) I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project. So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
I can't recommend a book however one thing I learnt, in my last job working with scientists, that saved me a few times, was how to approach developing something from scratch. You probably know this and if it comes across as patronising then I apologise - what I learnt was find out what he needs to do, not what he wants or even how he wants to do it. If you can find out what he needs to do then you might find that the solution presents itself and writing the solution should be easier. It also depends on which branch of science he works in. My experience with biological scientists was that they were very good at understanding high volumes of complex information, however as they were used to following prescribed recipes(using lab books) for their work they were not as used to thinking their way around problems as the some of chemists I interacted with who tended to have a better understanding of mathematics and logic. I would also say that as long as you stick to SOLID[^] software engineering principles you will be fine from the software side - it should also make it easier when he changes his mind.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development". I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality. I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.) I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project. So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
Look for courses at a MBA school specializing in Software engineering; or graduate level courses at a Computer Science school. Have a look at their curriculum and individual classes syllabus, sometimes they will even list book references. A quick google found something like this : Plan of Study - Software Engineering Masters Programs - Carnegie Mellon University[^] Good luck with that.
I'd rather be phishing!
-
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development". I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality. I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.) I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project. So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
I don't have any book recommendations, but I have done this kind of development many times in my 25+ year career. My degree is in chemistry, and I have worked on scientific software in the past. I start by collecting a list of "stuff the software needs to do". It is a high level list of what the scientist wants the software to do, such as "document some stuff", "read data from instruments", "perform calculations", "output reports". Explore each of these areas with the scientist to get more detail. Try to get an idea for the type of data you will need to handle in each "stuff the software needs to do" (network data, document data, key/value pair data, or maybe just regular old rdbms data). Now that you have a better idea about what needs to be done and what kind of data you will be handling, try to imagine the types of software best suited for each of the things (web ui/ mobile app/ databases/ services). You should start imagining how the different pieces will interact with each other, and deciding on an architecture for ui/data/services. There may be many different pieces, and each of them may use different tools (db, ui, services). Try to split out reusable parts into services so you can use them from web, desktop, or mobile clients; you can always run the services locally if you end up with a desktop-only system. Now as you start, keep things as simple as possible; do not introduce ANY unneeded complexity (especially imagined future complexity). If you include complexity early, design changes will be MUCH more difficult as you continue, but if you keep it simple as you go, it will be easy to modify as you discover new necessary features. Simplicity goes for the data as well; do not introduce some large db framework early, but wait until as late as possible. For example, with .Net, linq2sql is simple and flexible for fast progress. You may need to change to Entity Framework later, but it is much easier to update data structures in linq2sql than in Entity Framework (which has some issues with the update process). This will keep progress moving forward without drag from tool issues as changes will be happening very quickly in the early stages. As you continue, you will be able to refine your ideas about the amount of work involved, the time it will take to complete, and start setting milestones for continued development.
-
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development". I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality. I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.) I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project. So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
Not a book, but Joel Spolsky wrote a lot about the development of FogBugz and the ideas behind it. His weblog should be somewhere on Google and has some blogs on design and marketing decisions.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
I don't have any book recommendations, but I have done this kind of development many times in my 25+ year career. My degree is in chemistry, and I have worked on scientific software in the past. I start by collecting a list of "stuff the software needs to do". It is a high level list of what the scientist wants the software to do, such as "document some stuff", "read data from instruments", "perform calculations", "output reports". Explore each of these areas with the scientist to get more detail. Try to get an idea for the type of data you will need to handle in each "stuff the software needs to do" (network data, document data, key/value pair data, or maybe just regular old rdbms data). Now that you have a better idea about what needs to be done and what kind of data you will be handling, try to imagine the types of software best suited for each of the things (web ui/ mobile app/ databases/ services). You should start imagining how the different pieces will interact with each other, and deciding on an architecture for ui/data/services. There may be many different pieces, and each of them may use different tools (db, ui, services). Try to split out reusable parts into services so you can use them from web, desktop, or mobile clients; you can always run the services locally if you end up with a desktop-only system. Now as you start, keep things as simple as possible; do not introduce ANY unneeded complexity (especially imagined future complexity). If you include complexity early, design changes will be MUCH more difficult as you continue, but if you keep it simple as you go, it will be easy to modify as you discover new necessary features. Simplicity goes for the data as well; do not introduce some large db framework early, but wait until as late as possible. For example, with .Net, linq2sql is simple and flexible for fast progress. You may need to change to Entity Framework later, but it is much easier to update data structures in linq2sql than in Entity Framework (which has some issues with the update process). This will keep progress moving forward without drag from tool issues as changes will be happening very quickly in the early stages. As you continue, you will be able to refine your ideas about the amount of work involved, the time it will take to complete, and start setting milestones for continued development.
Thanks for the ideas, Scott. It's that starting paragraph that I am wrestling with right now (compiling the "what it needs to do" list). I suppose I was hoping for some step-by-step guidelines to help me navigate that jungle. But I guess it probably just boils down to good ol' brainstorming.
-
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development". I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality. I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.) I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project. So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
This is the book you want: The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP (Addison-Wesley Object Technology Series) 1, Per Kroll, Philippe Kruchten, Grady Booch, eBook - Amazon.com[^] I know you are going to think that the book is just about some methodology, but you have to see who wrote the book (Booch is one of the authors). Also, please don't focus on the fact that it mentions a methodology name. Methodology names are not important.
The process and what you learn from it is what is so valuable.
1. This book is all about thinking about how to approach an entire project. 2. It's about how to pull it all together while thinking from various stakeholder's positions. The authors have a lot of experience between them and it's a very good read. I think you'll find it quite informative and the next level of what you are looking for. EDIT: Check out this snapshot of the contents of chapter 4 -- basically mentions all the points you are talking about: http://raddev.us/images/rup.png[^] EDIT 2 Safari Books I'm a member too and the book is available on there too: The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP: Safari Books Online[^] You can even read the introductory chapter for free. EDIT 3 Direct mention of Greenfield project in the book: http://raddev.us/images/rup2.png[^]
My book,
-
This is the book you want: The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP (Addison-Wesley Object Technology Series) 1, Per Kroll, Philippe Kruchten, Grady Booch, eBook - Amazon.com[^] I know you are going to think that the book is just about some methodology, but you have to see who wrote the book (Booch is one of the authors). Also, please don't focus on the fact that it mentions a methodology name. Methodology names are not important.
The process and what you learn from it is what is so valuable.
1. This book is all about thinking about how to approach an entire project. 2. It's about how to pull it all together while thinking from various stakeholder's positions. The authors have a lot of experience between them and it's a very good read. I think you'll find it quite informative and the next level of what you are looking for. EDIT: Check out this snapshot of the contents of chapter 4 -- basically mentions all the points you are talking about: http://raddev.us/images/rup.png[^] EDIT 2 Safari Books I'm a member too and the book is available on there too: The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP: Safari Books Online[^] You can even read the introductory chapter for free. EDIT 3 Direct mention of Greenfield project in the book: http://raddev.us/images/rup2.png[^]
My book,
-
Yeehaw, Raddevus! That indeed looks like a great resource -- Chapter Six in particular ("The Inception Phase") looks like it contains exactly what I was hoping for! Thank you very much! (Now how do I "accept" your answer? :) )
kdmote wrote:
The Inception Phase") looks like it contains exactly what I was hoping for!
I thought that was phase you'd be interested in. Glad to help. Enjoy. It really is a very readable book.
My book, Launch Your Android App, is available at Amazon.com.
-
Yeehaw, Raddevus! That indeed looks like a great resource -- Chapter Six in particular ("The Inception Phase") looks like it contains exactly what I was hoping for! Thank you very much! (Now how do I "accept" your answer? :) )
kdmote wrote:
Now how do I "accept" your answer
Hover to the upper left and you will see a green/red arrows, alright triangles, click the green one. The red one has been disabled due to abuse. This up ticks his reputation which is the only way to reward a good response.
Never underestimate the power of human stupidity RAH
