How do you design your code?
-
The_Josher wrote:
I find a lot of the software industry in South-Western Ontario Canada (including TO), is focused more on time than on quality and reuseability. To me this seems ass-backward cuz if you write a giant, heavily-coupled, monolith you don't have anything to show for the next project and maintenance is a total pain.
Believe me, it's not only in South-Western Ontario... that's about all we do here in Western Canada. As for my design strategy, I usually design from the data requirements - figure out what you need to store & recall, and the methods to handle the data can come from that. Of course, I'm a junior web developer, so that's probably not the best way to go about it.
I was guessing at the rest of the software industry was probably like this. Especially if you are embedded into a corporation where the main line of business is not software. I'm sure MS and other old software houses mostly have their ducks in a row, but from my experience. No one cares unless the project adheres to a totally arbitrary date "in the sky". As for your data "store & recall", it's not a bad strategy. I always build a Facade over the database so I can ditch the database coupling if I need to reuse the business logic. The MS databinding idiom helps with this. Supply me the data you want something done with and I'll return you something that you want.
-
I’ve been trying out different methods for planning out projects and code. I've tried some things like mindmanager http://www.mindjet.com/us/[^] and freemind but still usually end up just typing a rough draft/outline in visual studio and fill in the blanks from there. So, I was wondering what everyone else uses for this sort of thing? Is there a built in productivity tool for doing your code architecture that I'm missing or a nice third party app that gives me a nice visual representation for colleagues but doesn't slow down my code writing process 'Thanks 'DrewG
Personally, I like to start with an understanding of what the s/w is going to do. If I can't explain what it is going to do in english, I am not ready to start writing the code. Of course, writing a complete spec isn't possible, or even desireable, but a big picture understanding is key to avoiding rewrites. I also try to think about the different kinds of users my program will have. Some users need a single button that does what they mean, darn it. Others need a lot of knobs. Often, supporting both types is easy if you design the system that way up front. Next, I think about the parts of the system and decide what each part is going to do. I also try to decide how I can test the parts. It does no good to write code that can't be tested. Design for testability is an art, but can help prevent a lot of grief. Next, I decide what programmatic interfaces each part will provide. For each interface, I try to write a trivial example of how that interface is going to be used and make a judgement of how much data will flow through the interface. Different data volumes require different interfaces. For example, java ODBC is very slow compared to writing a special sql call designed to handle megabytes of data. But, if you are only fetching the data for a single web page, who cares. Also, some interfaces are going to be obviously error prone -- experience can be the guide here. So, I try to decide interfaces that won't be a stumbling block for myself later or for other developers. Next, I document this example program in the comments of the s/w I am writing so I can refer back to it later -- and I update the example when I see I guessed wrong as I write the code. Next, I implement the pieces and test as I go. I make sure that all my interfaces are tested. You can't always test every if statement in the code itself, but you can surely call all the functions at least once with realistic data. Test Driven Development makes a lot of sense, but I like to write a little code first, then test it. During this phase of development, I make use of valgrind on linux, or purify on unix and windows. I also use purecov to make sure that every line of code in my s/w is exercised at least once during my tests. In my opinion, these tools are essential to getting the code written properly. Lowell
The chief cause of problems is earlier solutions!
-
I’ve been trying out different methods for planning out projects and code. I've tried some things like mindmanager http://www.mindjet.com/us/[^] and freemind but still usually end up just typing a rough draft/outline in visual studio and fill in the blanks from there. So, I was wondering what everyone else uses for this sort of thing? Is there a built in productivity tool for doing your code architecture that I'm missing or a nice third party app that gives me a nice visual representation for colleagues but doesn't slow down my code writing process 'Thanks 'DrewG
The application has it's own design built in; my job is to find that design and uncover it.
-
The application has it's own design built in; my job is to find that design and uncover it.
Zen development
I'm largely language agnostic
After a while they all bug me :doh:
-
I’ve been trying out different methods for planning out projects and code. I've tried some things like mindmanager http://www.mindjet.com/us/[^] and freemind but still usually end up just typing a rough draft/outline in visual studio and fill in the blanks from there. So, I was wondering what everyone else uses for this sort of thing? Is there a built in productivity tool for doing your code architecture that I'm missing or a nice third party app that gives me a nice visual representation for colleagues but doesn't slow down my code writing process 'Thanks 'DrewG
You have to keep in mind when you ask such a question here that most of the replies will be from people that have never had to design a truly large application and so it's easy to just say "I just start writing" etc. I'm guessing you mean something large. I start with Paper and pencil usually. I start out by plotting out the tasks that the users will want to accomplish, I think about how to design the app so that those tasks can be accomplished as easily as possible in as few steps as possible then I write it out as the end result I want to achieve complete with rough sketches of screens and forms etc, then work backwards writing a list of business objects that will be required. I *always* think of the user interface very early in the design stage once I know for certain what tasks will need to be performed. I don't mean tasks as in "user clicks on blah blah" I mean tasks as in work related or real world related tasks, i.e. "User makes an invoice" etc. I tried a UML modelling program for our last big project, in the end it was a complete waste of time because we tried to use it for the actual early design phase and then ended up changing it constantly and it became a giant pain in the ass. I think the best way is to go through the paper and pencil stage plotting it out like a storyboard for a movie, come up with the business objects that are required, list it all out, then enter it into a simple list in a document or spreadsheet with the requirements and details about each object and code from there. The important bit, no matter how you do it, is to think from the users perspective of the tasks they want to accomplish and have the UI planned out in advance. It's the single most important part of any software that will be used by a lot of end users and it's vital that it flow properly and be simple to use and be task oriented in the way that the end user will think. Too many projects end up crappy and hard to use because a geek designed them thinking about the "data" first and not the actual real world tasks that need to be accomplished. When you think about tasks first you end up writing an app that works the way the user wants it to work, simply and intuitively and you easily find ways to combine things and simplify things before you ever write a line of code. I honestly don't think any software is useful for designing an application because they lock you out of the proper creative mindset that you need to come up with truly great things.
"I don't want more
-
You have to keep in mind when you ask such a question here that most of the replies will be from people that have never had to design a truly large application and so it's easy to just say "I just start writing" etc. I'm guessing you mean something large. I start with Paper and pencil usually. I start out by plotting out the tasks that the users will want to accomplish, I think about how to design the app so that those tasks can be accomplished as easily as possible in as few steps as possible then I write it out as the end result I want to achieve complete with rough sketches of screens and forms etc, then work backwards writing a list of business objects that will be required. I *always* think of the user interface very early in the design stage once I know for certain what tasks will need to be performed. I don't mean tasks as in "user clicks on blah blah" I mean tasks as in work related or real world related tasks, i.e. "User makes an invoice" etc. I tried a UML modelling program for our last big project, in the end it was a complete waste of time because we tried to use it for the actual early design phase and then ended up changing it constantly and it became a giant pain in the ass. I think the best way is to go through the paper and pencil stage plotting it out like a storyboard for a movie, come up with the business objects that are required, list it all out, then enter it into a simple list in a document or spreadsheet with the requirements and details about each object and code from there. The important bit, no matter how you do it, is to think from the users perspective of the tasks they want to accomplish and have the UI planned out in advance. It's the single most important part of any software that will be used by a lot of end users and it's vital that it flow properly and be simple to use and be task oriented in the way that the end user will think. Too many projects end up crappy and hard to use because a geek designed them thinking about the "data" first and not the actual real world tasks that need to be accomplished. When you think about tasks first you end up writing an app that works the way the user wants it to work, simply and intuitively and you easily find ways to combine things and simplify things before you ever write a line of code. I honestly don't think any software is useful for designing an application because they lock you out of the proper creative mindset that you need to come up with truly great things.
"I don't want more
A Great Post! I always wondered what another dev would think if they saw me scribbling all these scenarios and object layouts on notebook paper.ie mary sells a product, betty adds a new product category, bill adds monthly discounts to products(I like to have a name on my fake users;)) I appreciate your insight into design applications as well, I have found mindmanager/freemind to be pretty fast moving and not as restrictive to my process while allowing me a way to unclutter/hide certain thoughts. But.. It sure doesnt decrease my dev time, as I dont have a way to generate code/UML based off of it(although I think I may have given myself an idea for my next project :-D) NeWay Thanks A lot for posting
-
Here's my perspective as someone who has returned to programming after a break of 20 years (who stole my Pascal compiler and my 6502 assembler?) - when all these fancy design aids weren't even dreamt of! Here, I'm not referring to anything big, just an addition to a project that will probably not require more than 3,000 lines or so. Working on my own app I get nobody to give me a set of requirements so the first step is always to make the decision as to what is the most useful functionality to include out of the list of ideas that is always at the back of miy mind. I decided there was one feature that was of vital importance to add to the (nearly complete project). I spent most of the weekend just thinking about this from a user's point of view. By definition, the process would have to involve quite a bit of user interaction so what would be the easiest method for a user? Having narrowed this down to two techniques, I then began to think about (roughly) how I could accomplish the task, in outline and two different "technologies" soon became leaders of the pack. I preferred the use of one (because it involved one less step that the user could get wrong) but thought it might be a lot harder to implement than the other. Spent a few hours experimenting with a test (on the harder method) to extract and analyze data from a certain file type to ensure that I could do what I wanted. It worked thus deciding whih technology to use. The result of this test re-inforced further thought about which way to implement the process from the user's point of view. I'm now strting to think about how the UI should behave and this leads to thoughts about data structures, what the user could do "wrong" etc. I then started to design some pages of user information as though I was writing an insruction manual. Get someone else to read it. Is it as clear as you imagined? At this stage, the words can run away with you and suddenly you have a document three times the size you imagined as the brain suddenly thinks of refinements or problems that hadn't occured to me before. With the big decisions taken, I then used Word (yeah sorry) to type out a skeleton design in what, in 1983, was called pigeon Algol. This tended not to get down to the method level but quite close to it. From this position, it was very quick to go to code. Day 1 (Monday) and I have 1250 lines of code, unit tested and working which is far superior to my output when I've started to code with a less clear idea of what I want to achieve. I genu
Thank You Very Much For The Great Post! There is no greater gift than insight from experience. It is great to see what veteran developers do to get the job done.
Rich Leyshon wrote:
Finally, as someone who has been 'out of the game' for a very long time - back when I was at University, the talk was of systems that would allow someone to "define the problem" rather than "define a solution." With the problem dfined properly, program generation would be fully automated.
I always get this type of vibe from Sharepoint(it seems the goal is to eliminate internal development) but that's probably just the paranoia talking. Hey if we keep creating a new language every few weeks we get to stay one step ahead of the code generating pc's :laugh:
-
You just do it. In all sincerity - it's just sort of there. Or, put another way, you kind of know what to do. Some of that comes from experience - but much of experience is learning defensive techniques against the enemy hoards (i.e., end users). Now, that doesn't mean you don't occasionally slash-and-burn something (visual or code), and I don't mean because the specs were changed. You will occasionally have a rethink. The rest is simply problem solving for the occasional new situation (grin). How matter-of-fact it all is! In all seriousness, I counsel you against too many bells & whistles in your design tools. They should be there to do the dirty work when you are manifesting your thoughts. When you stop getting "I just thought of a better way" moments, you may consider seeking employment in a less challanging environment.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
Thanks, I try not to get too caught up in design unless I know that I probably won't be doing maintenace or all of the dev for that matter. Then I just try and make everyone else's job easier by forcing them all to start from my page ;)
Balboos wrote:
When you stop getting "I just thought of a better way" moments, you may consider seeking employment in a less challanging environment.
:laugh: I couldnt agree more
-
Not very hight tech, but I use a pen and notebook. I have tried software and such, like StarUML, but I realized that I would have to learn so much just to make it right that I went back to a pen and paper. I will still learn UML, just not "today".
Ben
-
For me, it's all about breaking the problem into chunks that are small enough that I can get a real grasp on them. I'll likely document them with some form of 'box and line' drawing that illustrates the layering of the components or their interactions and some text that gives the scope and responsibilities of each of the components. I've always been of the opinion that you don't want to get too het up about the design - I've worked on safety-critical projects that (quite reasonably, given the constraints on these projects) have very detailed design. You really don't want to do that for your average PC application.
Stuart Dootson wrote:
I've worked on safety-critical projects that (quite reasonably, given the constraints on these projects) have very detailed design. You really don't want to do that for your average PC application.
Agreed on that.. Now if only I could work on the "average" pc application ;P
-
werD420 wrote:
Woohoo! I couldn't help but think of the other night when I thought about my mindmap "I need some background colors to add some distinction to this"
check out the clouds... a nice cyan cloud for configuration, a nice magenta cloud for drawing (drawing is a "warm color" operation). A distinct green is good for realtime I/O (very important, needs to stand out, plus green means "go!"). And remember, parallel operations are always a cool color. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I usually read all I can about the inputs and outputs and requirements (if there are any) and then take a nap. After that I usually have a really good idea on what I'm going to do. I usually write down a few notes to remind me what I'm going to do so I don't forget. I then drink a redbull type out the code. After the app is complete my boss comes back to me and says we need to do design reviews and code reviews. (So I take another nap :laugh:) Joe Q PS This is how I really do it except for the last nap.
-
How I design my code depends a lot on the size and scope of the project. If I'm just writing a new module for an existing system, I'll probably take an existing module and just modify that, with very little actual "deisgn" involved. If I'm working on a new single program I tend to do a lot of brainstorming and note taking with basic pen and paper. If I'm working on an entirely new system, I'll spend a lot more time with the planning, but it's still mostly pen and paper. I find that medium much more conducive to creative thought that any software I've tried. For the most part the mechanics of using a software package for planning and design just gets in the way of my creative process (whatever that is) and hinder rather than help. If someone every manages to design a program that enhances rather than interferes with the design process they could make a fortune.
Meddle not in the affairs of dragons, For you are crunchy, and good with mustard.
tsdragon wrote:
If I'm working on an entirely new system, I'll spend a lot more time with the planning, but it's still mostly pen and paper. I find that medium much more conducive to creative thought that any software I've tried.
Id always found paper to be my easiest method for this type of thing as well until I started working with different people in different locations. Now I seek standardization because my notes can be misinterpreted and are hard to be reused if I have to pass those along. Thanks for a great post and for the insight into your process!
-
I am using the old school which means analysis and then design. Using analysis methodologies like bottom-top and then top-bottom (which take more time than today expectations) will give results very accurate. What tools for design? You can use pencil and paper is necessary (but you will have to know at least one or more methodologies), the most important is to understand methodologies like bottom-top and/or top-bottom. At the end you will have OOT,P,D,A, etc. Programming will be extremely easy since you will have everything on pseudo-code. :-D Roberto
-
My approach is different depending on the project. I often start with the user interface for several reasons: 1. The user interface gives me feedback earlier, reducing the chance I'll waste time on something that has to be rewritten. It also gives me ideas on cool features to have, from playing around with it. 2. It drives the following development, as it's clearer what needs to be done to implement the functionality. 3. It gives me a way of immediately testing the features I write. Next I often try to get a simplistic case working, even if most of the subroutines and classes are just stubs that return a constant or print a message. At this point, some of what needs to be done is clear (cohesive classes/subsystems), and some is unclear. I work on the clear parts because it reduces the chance I'll need to rewrite them, and implementing them gives me a better idea how the unclear parts need to be implemented. For some cohesive functionality, I'll create a separate toy project just to play around with it, without all the other baggage. Once it's working, I'll move the relevant classes into the main project. Design Patterns are useful in implementing subsystems, but, contrary to the name, aren't very useful in designing the software architecture. With the popularity of object-oriented development, many programmers seem to have forgotten the lessons learned from function-oriented development (e.g. Constantine and Yourdon's Structured Design methodology): Short, simple functions that push the complexity down to lower-level functions. Structured Design complements object-oriented design, and I use it to make my methods simple and understandable. This has many benefits: 1. The low complexity of simple, short methods reduces the chance of bugs. 2. It makes methods more reliable. 3. It makes maintenance easier (for me and others), since each method can be understood immediately (as opposed to staring for hours at a 200-line method, wondering what it does). 4. It makes documenting the method easier; the functionality can often be succinctly captured in one or two sentences. This further improves understanding by maintenance programmers, reducing maintenance costs. During development, I have a working system at all times. As soon as I get something working or fix a bug, I back up the whole system to a sequentially-numbered backup directory. Then I feel free to aggressively pursue the next development step, knowing I can easily back up to a working version.
This is why I chose CP for such a post. The value of the expereince floating around here is unmeasurably great. I generally start from a user centric layout as well and create requirements/needs from there. I really appreciate your insight on this and as a result, will now be studying up on Constantine/Yourdon to make sure that I fully understand their methodologies and how to implement them. Thanks Again DrewG
-
Personally, I like to start with an understanding of what the s/w is going to do. If I can't explain what it is going to do in english, I am not ready to start writing the code. Of course, writing a complete spec isn't possible, or even desireable, but a big picture understanding is key to avoiding rewrites. I also try to think about the different kinds of users my program will have. Some users need a single button that does what they mean, darn it. Others need a lot of knobs. Often, supporting both types is easy if you design the system that way up front. Next, I think about the parts of the system and decide what each part is going to do. I also try to decide how I can test the parts. It does no good to write code that can't be tested. Design for testability is an art, but can help prevent a lot of grief. Next, I decide what programmatic interfaces each part will provide. For each interface, I try to write a trivial example of how that interface is going to be used and make a judgement of how much data will flow through the interface. Different data volumes require different interfaces. For example, java ODBC is very slow compared to writing a special sql call designed to handle megabytes of data. But, if you are only fetching the data for a single web page, who cares. Also, some interfaces are going to be obviously error prone -- experience can be the guide here. So, I try to decide interfaces that won't be a stumbling block for myself later or for other developers. Next, I document this example program in the comments of the s/w I am writing so I can refer back to it later -- and I update the example when I see I guessed wrong as I write the code. Next, I implement the pieces and test as I go. I make sure that all my interfaces are tested. You can't always test every if statement in the code itself, but you can surely call all the functions at least once with realistic data. Test Driven Development makes a lot of sense, but I like to write a little code first, then test it. During this phase of development, I make use of valgrind on linux, or purify on unix and windows. I also use purecov to make sure that every line of code in my s/w is exercised at least once during my tests. In my opinion, these tools are essential to getting the code written properly. Lowell
The chief cause of problems is earlier solutions!
-
I’ve been trying out different methods for planning out projects and code. I've tried some things like mindmanager http://www.mindjet.com/us/[^] and freemind but still usually end up just typing a rough draft/outline in visual studio and fill in the blanks from there. So, I was wondering what everyone else uses for this sort of thing? Is there a built in productivity tool for doing your code architecture that I'm missing or a nice third party app that gives me a nice visual representation for colleagues but doesn't slow down my code writing process 'Thanks 'DrewG
I like Enterprise Architect http://www.sparxsystems.com.au/[^] It's much cheaper than most other similar programs, and I've been quite pleased with the past few versions.
-
My approach is different depending on the project. I often start with the user interface for several reasons: 1. The user interface gives me feedback earlier, reducing the chance I'll waste time on something that has to be rewritten. It also gives me ideas on cool features to have, from playing around with it. 2. It drives the following development, as it's clearer what needs to be done to implement the functionality. 3. It gives me a way of immediately testing the features I write. Next I often try to get a simplistic case working, even if most of the subroutines and classes are just stubs that return a constant or print a message. At this point, some of what needs to be done is clear (cohesive classes/subsystems), and some is unclear. I work on the clear parts because it reduces the chance I'll need to rewrite them, and implementing them gives me a better idea how the unclear parts need to be implemented. For some cohesive functionality, I'll create a separate toy project just to play around with it, without all the other baggage. Once it's working, I'll move the relevant classes into the main project. Design Patterns are useful in implementing subsystems, but, contrary to the name, aren't very useful in designing the software architecture. With the popularity of object-oriented development, many programmers seem to have forgotten the lessons learned from function-oriented development (e.g. Constantine and Yourdon's Structured Design methodology): Short, simple functions that push the complexity down to lower-level functions. Structured Design complements object-oriented design, and I use it to make my methods simple and understandable. This has many benefits: 1. The low complexity of simple, short methods reduces the chance of bugs. 2. It makes methods more reliable. 3. It makes maintenance easier (for me and others), since each method can be understood immediately (as opposed to staring for hours at a 200-line method, wondering what it does). 4. It makes documenting the method easier; the functionality can often be succinctly captured in one or two sentences. This further improves understanding by maintenance programmers, reducing maintenance costs. During development, I have a working system at all times. As soon as I get something working or fix a bug, I back up the whole system to a sequentially-numbered backup directory. Then I feel free to aggressively pursue the next development step, knowing I can easily back up to a working version.
Oh my lord - I've a long-lost twin!* *Except my backups are zipped images of my entire development directory structure. -- modified at 7:29 Wednesday 18th July, 2007
"Good Fortune is when Preparation meets opportunity"
-
You have to keep in mind when you ask such a question here that most of the replies will be from people that have never had to design a truly large application and so it's easy to just say "I just start writing" etc. I'm guessing you mean something large. I start with Paper and pencil usually. I start out by plotting out the tasks that the users will want to accomplish, I think about how to design the app so that those tasks can be accomplished as easily as possible in as few steps as possible then I write it out as the end result I want to achieve complete with rough sketches of screens and forms etc, then work backwards writing a list of business objects that will be required. I *always* think of the user interface very early in the design stage once I know for certain what tasks will need to be performed. I don't mean tasks as in "user clicks on blah blah" I mean tasks as in work related or real world related tasks, i.e. "User makes an invoice" etc. I tried a UML modelling program for our last big project, in the end it was a complete waste of time because we tried to use it for the actual early design phase and then ended up changing it constantly and it became a giant pain in the ass. I think the best way is to go through the paper and pencil stage plotting it out like a storyboard for a movie, come up with the business objects that are required, list it all out, then enter it into a simple list in a document or spreadsheet with the requirements and details about each object and code from there. The important bit, no matter how you do it, is to think from the users perspective of the tasks they want to accomplish and have the UI planned out in advance. It's the single most important part of any software that will be used by a lot of end users and it's vital that it flow properly and be simple to use and be task oriented in the way that the end user will think. Too many projects end up crappy and hard to use because a geek designed them thinking about the "data" first and not the actual real world tasks that need to be accomplished. When you think about tasks first you end up writing an app that works the way the user wants it to work, simply and intuitively and you easily find ways to combine things and simplify things before you ever write a line of code. I honestly don't think any software is useful for designing an application because they lock you out of the proper creative mindset that you need to come up with truly great things.
"I don't want more
How many lines of code (or actual users, or whatever is the measure) does it take for you to qualify something a "truly large application? Is this a good place for 'size doesn't matter'? That's never really true (not even in it's normal context). But, come once we've reached some reasonable threshhold in size, it's technique that dominates. I feel the need to object to the idea that the scenario really changes significantly. Ultimately, a program has a core (perhaps we'll call it main() ?). This entry point has options. Some of these options have options, &etc. If you've been programming a while, the majority of what you'll do is what you've done [Oh, my precious ego! It's fallen and it won't get up]. The fun part is those unique problem-solving scenarios: how often is that the whole shootin' match? (It is a reason why the world continues to need live programmers). By and large, a big application is pretty much a lot of little applications with a exceptionally good data/state connections. Perhaps I abstract this whole thing too much? I've been contimplating (as I type) some of the considerations I have to emphasize as the lines of code mount - but actually, it seems like the same rules still hold - the distinctions are minor. Particularly if you make it part of your modus operandi to reuse the same objects throughout the application. But, that's sort a standard consideration, so where's the real difference? The labor is a labor of love, spawned of creativity.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
-
Thanks, I try not to get too caught up in design unless I know that I probably won't be doing maintenace or all of the dev for that matter. Then I just try and make everyone else's job easier by forcing them all to start from my page ;)
Balboos wrote:
When you stop getting "I just thought of a better way" moments, you may consider seeking employment in a less challanging environment.
:laugh: I couldnt agree more
I threw in a few other answer to other comments, but I'll give you the following philosophy (of mine) for consideration: Don't think "outside the box." You shouldn't have a box.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein