How do you design your code?

[Stuart Dootson]

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.

[dazfuller]

It depends, at work if I'm starting a large project I'll design it all in UML first. We've just started using Enterprise Architect for that and it can create you're base classes and method stubs for you but I'm kind of picky over code layout and presentation so I code it all by hand anyway. At home and for some smaller projects I'll sketch out a diagram of what I want first, build the business objects, design and write the data access layer if I need one, write the presentation layer, hook it all together and then create the GUI. You know I can remember a time when I'd just write it and re-factor it if needed, when the hell did this start getting so long and complex? One thing I'll avoid at all costs is anything which creates code for me (except for the GUI part), I use to use Dreamweaver and that tainted my opinion of automatically generated code for life. Now I'm going to go and get a coffee, review a weeks worth of Dilbert cartoons and reminisce about the good old days when programming was programming and not object lifetime diagrams :laugh:

[paulgafa]

Coding without a plan??? how can you see your targets... Even Harry Potter had a plan and that made it successful!!!!

[Rich Leyshon]

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

[Feng Qi]

I think mindmanager and freemind are too hard for me. So I use paper and pencil or visio instead;P

[W Balboos GHB]

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

[Joe Q]

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.

[ednrgc]

Programming and design are 2 different things. There are plenty of "programmers" that believe they are great architects, but are not. Then again, there are plenty of architects that believe they are great architects, but are not. :)

[DJ van Wyk]

Just start typing ideas and build on them as I go along. Eventually rewrite everything to make it more usable. Definitely not the best way, but it works for me.

[The_Josher]

To be honest, I'm very design heavy. I often come up with solutions that is a bit of overkill. The reason why I do this is I want something for free after my given project is done. So if a control is needed, then I make sure that I push my assumptions out to some form of config file and then everything else is really general. That way, being the "lazy programmer" that I am, I get to take that control with me to other projects. Sooner or later, I look like a super star with a large bag of magical tricks. As for design tools, I use UML on paper (I like to write OO if available in the given language). I also use the internal tool in VS2005 that is quasi-UML. I think it's called class designer. As for conceptual models I use Design Patterns. Why should I have to come up with robust conceptual solutions when its already done for me :) ? 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. I could go on forever. Have fun.

[The_Josher]

Actually, I'd like to hear this too. The Class Designer in VS2005 is a little on the weak side. Better tools are great. But to be honest, I don't want to have to pay 10K$ for one of these either. That seems to be more the case than anything for UML to code tools.

[tsdragon]

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.

[Roberto Perez]

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

[Alan Balkany]

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.

[deltalmg]

Good way to go. I've had the same happen. How long will it take you to make this work? About 3 weeks? Then I have it to them by the end of the day and they think I'm a god. There are a lot of UML tools that will generate the module headers for you. This can save you some of the time used for designing. Plus, again you'll have someone thinking your a god, when they have to maintain your code, and you actually have some nice pictural documentation for them. As well, if you go nuts with the UML you don't have to comment the code as much IMHO. I'd just comment the obscure algorithm/command parts.

[The_Josher]

That's fabulous. That's the end point that I'm looking for. I don't retain rights to my software so I usually have to rebuild any toolkits that I create for a given client. Yep, I'm working on that. Right now my concentration is building abstracts/interfaces that any system I touch gets a copy of. That way I can have a lingua franca for all of them. Sooner or later, all those systems become very simple to do nifty dependency injection or other super cool tricks.

[Chad Emm]

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.

[The_Josher]

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.

[Lowell Boggs]

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!

[PIEBALDconsult]

The application has it's own design built in; my job is to find that design and uncover it.