We Keep Coding

Application design for 5 years

My question is not technical. It's more of a philosophical and really down to individual preference. I am designing and developing an application (web + desktop) and this just occurred to me and was wondering if you guys (programmers and designers) ever came across this before:
Some designers believe in making applications that will run 3-5 years down the line and any changes that come to them will be reflected on them without any need to resort to system core changes. As a programmer I know for a fact that this is never the case. Small cosmetic changes do occur but usually they die away after a year or two, as time progresses there will be changes that will require core changes and eventually you will make a new application.
Given the fast paced changes of technologies, designing an application for 5 years down the line is rather absurd, IMHO. Well I mean not designing, but the idea that this application will run for 5 years and the belief that we will not need to create a new one I think is living in a fool's paradise. I mean really, fellow programmers, most mission critical or basic small application that have a running flow usually are re-made/re-structured/re-organized/re-coded few years down the line anyway.
So my question is why keep to this attitude of having this perfect application that will run for a decade. It's stupid really, because you know for a fact that technology will change every year; new frameworks, new methods, new technologies will emerge and your client will want them. So, if you forgive my use of this phrase, WTF is the point?
I keep telling my designer that the application will be redesigned in a few years anyway, there is no point in trying to make it shoot lighting from its #ss because it just won't, ever. There is no such thing as a perfect application.
I hope you guys get my drift. Have you guys felt the same way too. BTW I have been in the software programming business for about 7 years now. If you really think about it, do you really think Facebook will remain the same 5 years down the line, for sure the design will change every year or so to remain "funky" but the core will change every couple of years. I am dead sure of that. Am I paranoid or what? Please tell me there are other programmers in the same road as I am. Anyone?

My approach is to design for change. This means writing the most maintainable code I can, keeping things loosely coupled and modular, trying to do things in as standard a way as possible so that other developers can quickly pick up on the code, etc.
I usually put a little more effort into future-proofing the database design, as changes there can be a lot more difficult than code changes in many cases.

I have worked at two different companies which had software products that were nearing 10+ years old. Although they had been extended with tons of new functionality and had been given many face-lifts, the core of the application was essentially untouched since the first stable release. This may not be typical, but if the architect is skilled enough, the system can be built to be modular and extensible enough to accommodate a surprising amount of growth.

"The biggest roadblock to a great plan, is the dream of a perfect plan."
I agree - designing the perfect system which can be elegantly resilient to every possible future change, is fruitless. Every successful project is a tradeoff: building flexibility where you're confident it will be needed (or where it's easy to do anyway); and building somewhat quick-n-dirty code where you believe flexibility/change is unlikely. If you analyze the system well and the client has a good idea of their needs/requirements (not always a given), you'll get that balance right at least most of the time.
However, the idea that the whole system will be replaced every 3-5 years by some newer technology is also a fallacy. For every client who wants the latest, newest, sexiest system, there's 5 clients that are afraid to part with (or can't afford to replace) their legacy COM/VB/MS-Access/whatever system that is a morass of spaghetti logic built-up haphazardly without regard to maintainability, flexibility, or extensibility. You don't want to be the one building that system; if you are, then you're doing your client/employer a disservice.

Personally, I would never set out designing any sort of app assuming it is going to be replaced within a few years. It is all to often those 'updates' and 'rewrites' get pushed off for quick fixes desired by customers who don't want to wait for an entire new application. Sure the requirements change, features are needed, but often they will be desired in the current iteration.
I mean, there are a lot of apps, languages, and design patterns out there that thought the same thing, and are still in use today. One that pops into my head is the y2k bug. Programmers in the 70's never thought their code would last 30 years, and surely someone would expand those year values to 4 numbers before the turn of the century. We all remember how that thinking turned out...

I beleive that if the core of the system is built on principles that haven't changed much in many many years, then the system fundamentally will not change much, most changes would be primarially aesthetically.
Some tried and tested principles that remain strong to this day are for example database normalisation, modularisation of code etc etc.
So it depends what you define as the core. For me, the core means the design of the system, which if done properly probably wont change much at all in the future.

It really depends on the environment. I find that our internal corporate applications are fully overhauled (often retired) within 18 months of launch. It isn't anyone's fault - business priorities change, requirements change, new systems come online. At the same time other system run for a very long time.
We certainly don't develop any application with the expectation that it will soon be retired but there are business needs that need immediate solutions and sometimes it is better to get the app online and in the hands of the end-users as soon as possible. We update, iterate, and determine the next best steps.

The data and data structures (often) need to be legitimately designed to last for decades. The algorithms, UI and everything else is expected to evolve rapidly.
If your data represents legal documents, financial records, you might be required to hold on to it for decades.
This, too, though can be taken to extremes. There are subsets of data that probably no one will care about in 50 years, like memory performance counters that might have been stored in the database.

I remember a quote from James Kovac I believe, in one of the .Net Rocks' podcasts where he described our industry as:
one where the only constant is change
which is why you should design for flexibility so that when changes come, and it inevitably will in most cases* you will have an easier job adapting/updating your application. That's not to say you shouldn't try to build your application on solid grounds, but just more important to have a flexible solution which you can change easily than the perfect solution the first time around.
*I know in lots of banks people are still using ancient applications because it's too risky to change them and they simply don't have the expertise to change them anymore..

Well I think the ideal design is completely orthogonal, but you just have to accept that it rarely works out the way you envisage. If you've never read The Pragmatic Programmer, it talks a lot about future-proofing your code.

How do you handle large projects? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've just inherited a large project previously coded by about 4-5 people. The documentation consists of comments, and is not very well written. I have to get up to date on this project. How do I start? It consists of many different source files. Do you just dig in? Are there tools that can help visualize the structure/flow?

If you have a chance, I'd try and talk to the original designers and developers. Ask them about any major design issues or shortcomings of the project. Is the project in good shape and only needs maintenance or are there major components that need to be added or reworked? What are going to be the biggest roadblocks to maintaining the project? Take one or two of them to lunch (separately) if you have a budget for it as they might be more free to talk about problems outside of the office.
Talking to the users is also important for getting a feel for the current status of the project. Quite often they have a different opinion of how things stand then the developers do. Make sure, however, that they don't start giving you a list of all the things they want added or changed - you should take a few weeks to understand the project before you can start making major changes to it.
As for visualization tools, I'd start with the database design if there is a database involved. Tools like Microsoft Visio can create a diagram from an existing database. I find knowing the design of the database helps me wrap my head around what the programmers were trying to accomplish. Visio is also good for documenting program flow with some basic flowcharts though you'll have to create them yourself - it doesn't generate them automatically as far as I know.
Good luck.

I would encourage you to buy and read this book thoroughly. It provides you a LOT of information in this regard, much more than you will find here.

Brainstorming a little for you:
Step around in the application with a debugger, use a Static Code Analysis tool for which ever language you are working with...
Talk with people - both developers AND USERS to get a feel of the application.
Review the issue tracking system to see if you can see any recurring types of problem...

Are there tools that can help
visualize the structure/flow?
The latest Visual Studio 2010 allows you to generate architecture diagrams.
http://ajdotnet.wordpress.com/2009/03/29/visual-studio-2010-architecture-edition/

Try to find the starting point of the system and start digging from there. It sort of sucks to be in that situation, and chances are the comments might not be that helpful either. If the original developers didn't bother (or didn't have the chance) to document, chances are they never kept the comments up to date with code changes.
So time to bring the shovel... but don't just dig in blindly. One thing that is important is to understand what the system does from a users' perspective.
Concurrent with your code digging, you need to meet with a user (or the users' liason) and have him walk through the system, showing you how it is supposed to be used, for what purpose and what it and its subsystems are supposed to do. Moreover, attempt to understand what are the business pre-conditions and post-conditions of each major operation performed with this system.
Then map (or do a hierarchical) chart of the main functions of the system; classify them by category, purpose or module. If the system performs some sort of work flows or business transactions, attempt to chart some sort of state/transition diagram documenting each (and cross-referencing each state/transition to the subsystem or module in the system that is in charge for it.)
Once you have that, you can dig according to function. It will be best if you dig for a specific purpose, say, there is a bug fix to implement. You locate the logical module or category pertaining to that bug fix, you have the pre-conditions and post-conditions; then you can dig precisely on (or around) that bug fix.
If you just dig in without a guide (at least a high level one), you can be digging for months without getting anywhere (I'm telling you from painful experience.)
If there is no user manual, implement a draft according to your meetings with the users/users' liason. That could serve as a guide for implementing a developer's/administrator's manual for the system you just inherited (if there is ever a chance to implement one.)
If code is not on source control, put it on it. Doesn't matter what SCS you pick (could even be CVS, yuck!) What matters is to put it under source control asap.
Those developers didn't exist in a vacuum, they must have had exchanged emails. Identify other tech liasons they work with. Attempt to identify what other systems, if any, this system interfaces to (.ie. your databases, other's peoples databases, cron jobs, etc.)
But this could come at a later time. I think you should, for starters, focus on understanding how to use the system and what it is for. Let's call it understanding its business/knowledge architecture. Then dig according to that... or better yet, according to that and with the purpose of fixing a bug.
Good luck.

Use Profiler to see main functions and events in your project (the fastest way to learn framework)
Learn business logic very well to better understand the code
Documenting every new thing you learn - setup wiki (you will be surprised how quickly things are forgotten)
You can use Visio to draw Database Model Diagrams. (keep them close to you while studying the code)
These are the things that helped me when I inherited the previous project (50+ developers, 70+ GB database, 1 GB of source code and not even a single line of comments in code (maybe few :), and everything written in foreign language )

Use the debugger to walk through the application. That will let you go both deep and wide. You'll also be able to learn about how the code handles specific scenarios.
When you're ready to change something as #Jaxidian said, Working Effectively with Legacy Code is a great resource.

I was recently in a similar situation. What helped in my case was focusing on the changes I needed to perform on the project, and in the process of making those changes I learned about how the project is structured and so on. Sure, the first few tasks took a bit longer, but look on the bright side: I got stuff done and I got familiar with the project at the same time.

I'd suggest two things that may help:
Be productivity-driven. In other words, find a change that needs doing and use this to learn how that bit of the system works. Your changes may not be the most elegant without a whole-picture understanding of the software, but you will get work done within days/weeks.
Follow things from the user-interface. I.e if a change involves things a user does on a dialog, find that dialog in the code (relatively easy) and then work backwards to see what bits of the code provide data to the dialog, how the dialog interacts with the system, etc. Trying to find "where does X happen in the code" is very hard without good documentation, but finding "where is the code relating to this dialog" is quite easy and gives you an entry-point into the code.

Whenever I start a new project, I spend 2-3 days skim reading the code and making notes. I basically go through the entire solution from top to bottom and make a map in a text editor of each (significant) class in each project and what it appears to do.
The aim in doing this is not to completely understand the entire codebase, so don't worry if you feel you are not getting your head around it completely. The aim is that you end up with an index of where to go when you need to start on your first piece of work. You should also end up with a cursory picture of the solution in the back of your brain that will get filled in over the next couple of months. I always do this on the first few days as your superiors will not expect you to be productive during this time and you may never get another opportunity where you have the time to do so.
Also, do not rely on code comments for direction. Even with the best intentions they are often unmaintained and may lead to incorrect conclusions about what a class or section of code may do: a comment may lie but the code always tells the truth.

If you already have a team, you could charge each with a part of framework, and the result of their exploration should be registered somewhere, like a wiki. After that, give to each a task similar to something which is already done in the system (from the functional point of view)
For example: if a list of products is displayed in your app, you could display a list of orders (the complexity should be approximately the same), in the same manner it's done actually in the app. Than make it more interesting: try to edit it and save into DB.
Than switch the tasks and let the questions appear and than the first person who made the same task will show & explain how things are done.
Like that you'll see how the things are done pretty easy + your team will be up to date with this knowledge.

Presuming there is a database, start with the data model. Somewhere (Mythical Man-Month?) it was written "if I have your tables, I don't need to see your code."

Regarding potential tools, you may want to look into NDepend. It is a code-analysis tool, with an emphasis on highlighting the internal organization and dependencies of the code base (see this post for typical outputs), and spotting code quality issues. I have not used it personally, but Patrick Smacchia, one of the developers of the product, has a few posts where he applies NDepend to some classic apps (here is NUnit for instance) and discusses what it means, and I found them interesting.

Go and speak to the users or, read the manual and / or if one exists, go on a training course for the system (internal training departments will sometimes have put them together if there are lots of users).
If you don't know what it's meant to be doing then the chances of you being able to work out how it does it are close to zero.

Game engine development question [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am thinking of making a simple game engine for my course final year project. I want it to be modular and expandable so that I can add new parts if I have time. For example I would make a graphics engine that would be completely independent of the other systems, once that was finished I could add a physics engine etc.
I would also want to make a tool set to go with this engine. For the tools I would like to use C# but I am not sure about the libraries. My question is, if I want a C# GUI program, can I reference a library written in C++? Also would there be any performance problems etc. if I made some of the libraries in C# but wanted to use them from a C++ game.
I would like to avoid C++ as much as possible, my experiences have shown that development time can be a lot higher for a project over that of using C# or Java etc. My graphics development would be in OpenGL, this is all I have been taught. We have only done this in C++ but I have seen that projects such as SharpGL allow for the development with C#. Is there any performance issues with this. I am not looking for a blindingly fast, top graphics game. It will most likely be something simple to show my engine working. My engine probably won't be that great either as I only have a year and am working on my own.
Any advice on this would be appreciated. I am still really in the planning stages so it wouldn't be too much work to completely change what I want to do. I would just like to preempt any major problems I might have.
Thanks

If you can pull this off even under a relaxed set of goals, you're set for a great project. First, you need to get a grasp of scope:
How long do you have to work on the project?
How many people are working on the project?
If you can only create one "piece of the pie" on your own, which one would you pick? Use this to establish a working plan to make sure if you don't get as far as you'd like, you still have enough to make the work show as a great project.
A game engine is a big development task. A game engine with a toolchain is an enormous development task. In a lot of ways, choosing a smaller but more challenging task is preferable because it shows higher-level thinking about problem solving, which is greatly preferred by academics - double that if you are CS and not [Area of] Engineering. Since you are working in managed languages, things you may want to consider are:
Expressing gameplay logic (rules of the game) in a clean manner so as to provide an efficient and reliable path from designer->developer->tester. If you want, this could absolutely include the manner in which you describe the rules (Custom editor? Code API? DSL?)
Game AI has no shortage of extremely challenging problems.
Physics and graphics are interesting and I believe managed languages will eventually be used in these areas, but you may find yourself a bit more limited in your ability to solve these problems. If I were going to work in this area now, I would be trying to answer: "If I could use a managed language for writing [graphics|physics] code without hurting performance, what kinds of [language|runtime] features make the most difference in improving the expressiveness, correctness, maintainability, and reliability of the resulting programs." This goes way past simply having garbage collection and pointer safety.

You should look into XNA. It performs quite well, and from what I've heard, is quite easy to work with.
About referencing C++ code from C#: It's perfectly doable, though it will take some effort from your side to get it right. C++/CLI can work as an intermediate wrapper or you can use P/Invoke. Just remember that C++ is unmanaged and that you will need to do some manual garbage collection, which can be somewhat icky in a managed environment like .Net. Perfomance in the C++ -> C# bridge is okayish, but I'm unsure how it will perform if you need do 100.000 calls to a math-library each second. I guess a small test would be good.. I'll see if I get time to do this later today, though I somewhat doubt it :)

When creating a graphics engine (I'll only really speak about graphics as that is my area of expertise), these are a few of the choices you need to make EARLY in the project:
1) Is it an indoor and/or outdoor engine?
2) What sort of visibility system are you going to use?
3) Forward or deferred renderer?
4) How will you have animation hierarchies?
5) Dynamic or static lighting?
6) How are you going to handle transparency?
7) How will you handle a 2D overlay?
8) What mesh formats will you use? Roll your own?
Bear in mind you need a GOOD solid vector/matrix library and preferably a full maths library that will help with things from eulers to quaternions to axis-aligned bounding boxes.
Do a lot of research as well. Try to find out what the potential problems you are going to face are. Remember things like changing a texture or a shader can have HUGE impacts on your pipelining. You need to minimise these as much as possible.
Bear in mind that getting a rotating bump mapped mesh on the screen is simple by comparison to getting an engine running. Don't let this put you off. It should be no problem to write a fairly simple game rendering engine in a matter of months :)
Also ... find communities specific to this area. You will get a lot of good (though non-OpenGL-centric) information off DirectXDev. There is a fair bit of general game development algorithm information available at GDAlgorithms. There is also an OpenGL specific mailing list here.
Its worth noting that DirectXDev and GDAlgorithms, at least (I don't know so much on the GL mailing list) are populated by some VERY experienced 3D engine and game developers. Don't post up lots of "beginner" questions as this does tend to breed contempt among the members. Though the odd query or 2 at whatever level (beginner to advanced) will get amazing answers.
Good luck! I wish I'd had the chance to do this at University. I might not have gone off and joined the games industry and enjoyed an extra year of sleeping late ;) hehehe

Why do you need any C++ code?
There are already several wrapper libraries exposing OpenGL or DirectX to .NET, such as SlimDX (which, as the name implies, is a much thinner, more light-weight wrapper than something like XNA)
If you're more comfortable with C#, there's no reason why you couldn't write your entire game in that.
Performance generally won't be a problem. In most cases, the performance of C# code is comparable to C++. Sometimes it's faster, sometimes it's slower. But there are few cases where C# isn't fast enough. (However, there is a significant performance cost to interfacing between native and .NET code -- so doing that too often will hurt performance -- so the trick is, if you use native code at all, to have sufficiently big native operations, so the jump to/from .NET isn't done too often)
Apart from that, a word of advice: Don't bother writing an "engine".
You'll be wasting your time producing a big monolithic chunk of code which, ultimately, doesn't work, because it was never tested against the requirements of an actual game, only what you thought your future game would need.
If you want to experiment with game development, make a game. And then, by all means, refactor it and clean it up and try to extract reusable parts of the code. But if the code hasn't already been used in a game, you won't be able to use it to build a game in the future either.
The engines used in commercial games are just this, code extracted from previous games, code which has been tested, and which works.
By contrast, hobbyist engines pretty much always end up taking 2+ years of the developer's time, without ever offering anything usable.
The whole concept of a "game engine" is flawed. In every other field of software development, you'd frown at the idea of one vaguely-defined component doing basically "everything I need to make my product". You'd be especially suspicious of the idea that it is a separate entity that can be developed separate from the actual product it's supposed to support.
Only in game development, which is by and large stuck in 80's methodologies, is it a common approach. Even though it doesn't actually work.
If this is a school project, I'm sure whoever is supposed to grade it will appreciate it if you apply common good software practices to the field. Just because many newcomers to game development don't do that (and prefer to stick to some kind of myth about "engines"), there's no reason why you shouldn't do better.

Make sure your scope is feasible.
As a teenager I went through the build-my-own-engine phase, a few years later I realized I would have gotten a whole lot more done if I had just used pygame and pyopengl and not wasted the effort.
Check out the forums at gamedev.net.

Sounds to me like you have a pretty good plan for your project. (I get your point about XNA in your comment to #Meeh)
You can interop with C++ via P/Invoke directly or COM, you could also I guess come up with some SOA way of doing it, but to be honest as yucky as this sounds I would be inclined to target COM as your API lever of choice...why? because then you open up your API to a lot of common client language's not just C# and VB.NET you will also get Delphi, VBA, Powerbuilder etc.
Performance should not be a problem as the API entry points are just to kick of the work and transport data structures, the real work is done in your library in native code, so don't worry too much about the perf. ATL will be your friend with creating COM Classes that provide entry to your Library.

Whilst it's certainly do-able to bridge between C++ and C# (Via managed C++ is a good way to go if the interface is complex, P/Invoke for a very simple one), for tool<->engine communication I might suggest instead a network based interface. This is ideal for a high-ish level interface, such as you might want for a level editor/model viewer or such. An actual object modeller is not such a good target. What tools do you envision?
If you do it this way you gain the ability to connect to remote instances of the engine, or multiple instances, or even instances running on different hardware platforms. It'll also teach you a bit about sockets if you don't know them already.

How to write code in Visual Studio faster? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Whenever I start a new software project I spend a good amount of time at the beginning drawing class diagrams and other flow charts to plan out how I see the application working. This part just takes a lot of thinking and testing. But at a certain point when everything is planed out I don't need to think about it so much anymore I just need to code it.
IntelliSense is definitely a godsend, as is being able to generate code from it automatically by hitting the TAB key. But now I'm wondering: what are some other techniques or tools people use to get the code in their head to the screen as fast as possible?

I get a lot of productivity out of Resharper - It's especially useful if you learn all the features and keyboard shortcuts

As everyone else has mentioned, use Resharper or equivalent.
Learn the keyboard shortcuts and use them. Just about every operation you can perform in VS has a keyboard equivalent, and the more of them you know, the less time you'll spend poking around in menus. This is equally important for using Resharper.
Pay attention to anything you have to wait for. Are you waiting for builds to finish? Remove projects that you aren't working on from your solution and reference their assemblies instead. You can always add them back if you need to. Are you waiting for unit tests to run? Maybe you can segment the tests into a set you run several times a day and a set you run before every check-in. Are you waiting for your application to start up every time you test it? Maybe you can define a build configuration that excludes startup code whose functionality isn't involved in what you're working on right now.
Get a solid-state drive and put your OS and development tools on it. Put more memory in your machine.
A simple for tip for dealing with the tedium of editing code that you copy and paste: Don't copy and paste code. I'm sure that there are circumstances under which it's acceptable, even necessary, to copy and paste code, but if it's part of your everyday workflow you need to stop what you're doing and fix it. I wouldn't even mention this if more than one person hadn't suggested it.

I don't want to open a whole CodeRush & Refactor! / Resharper can of worms, but a good quality re-factoring tool like one of these would probably help enormously. I have been using CodeRush and Refactor! for a little over a year, and the time it takes to write robust and maintainable code is way shorter now than it was a couple of years ago.
Of course, there's a learning curve, but the benefits after just a few weeks are enormous.

Make your environment to respond faster.
Slow pc, IDE, build, repetitive tasks that could be automated kills speed seriously.
Every little thing counts. Even increasing Repeat rate in Control panel=>keyboard properties.

You could draw your class/sequence diagrams in a modelling tool like Enterprise Architect that can then generate the code for you.

I hate to be the one to bring this up and I'm no Linux fanboy but I tried an addin called ViEmu a few months back. It took me at least a month to get back up to my usual productivity because learning all the commands and how to chain them is a big ask but now,..I'm easily 5-10 times quicker at refactoring.
It kinda hard to explain how but you get the most work out of it when you come across text editing jobs that are awkward and repetitive it seems,..say you've got 20 lines of code where you need to remove the middle camel cased word from the variable name. It's that kind of thing.
The link for ViEmu is here - http://www.viemu.com/
HTH

Unfortunately for me it's just intellisense, although I do tend to re-bind a number of keyboard shortcuts to help. The context menu (my keyboard doesn't have a context menu button) is one of my most used for adding references etc.
I did read not too long ago about a 'neural headband' for gamers. It was designed to be trained so they could think 'forward' & 'fire' rather than pressing W + Mouse1, and claimed to increase reaction times. I doubt it could be trained up enough yet, but if technology like this could be used so you think 'implement base class Foo and add method Bar()' and the code is generated within VS, then that would be amazing :) Sadly it's a little way off, and I can imagine 'Coffee' being the result of far too many broken builds...

Good tools help a lot. I especially like Visual Assist X: http://www.wholetomato.com/

Have you thought about creating and using code snippets for things you do regularly? These can be a real time saver as you just dump them straight in and can easily refactor the variables used within them.

Well, no doubt I'm an oddball, but for desktop apps (not web) here's what I do. I consider almost any app as just a glorified editor. That is, it has a data structure that needs to be persistent, and a UI to let the user put information into that data structure and get it out.
For the data structure, keep it simple, simple, simple. I consider it just a repository for information, with as little redundancy as possible. I do not want to build data structure that exists for the purpose of being a visible manifestation of the underlying data, such as tree controls, etc. because then that needs to be kept in agreement with the underlying data, and you get into all the issues of how to keep redundant data consistent. (Example: for graphics, don't build it, draw it.) If I cannot avoid creating redundant data structure, I stay away as much as possible from notification-style programming that tries to keep redundant data structure in tight agreement. Much of the buglist and performance issues arise from that. Rather I prefer loose coupling, where a certain amount of inconsistency can be tolerated and is managed by processes that run once in a while to propogate changes.
For the UI, I was a big believer in OOP and MVC-style UI coding, until I discovered this in 1986. Now I'm spoiled, and I can get complex UIs coded in a fraction of the time possible by the usual control-event-handling style, and they are trivial to modify as requirements change. But so far, I'm in the company of maybe only 3 people in the world who use it, because it is definitely not mainstream.

It seems to me that I see two things:
You don't have a full keyboard. I can't recommend getting a new keyboard enough.
You could use templates to make it easier. I gather that you have to do a lot of programming before you ever get started on your project. If you would use templates, you could make a template containing all your exception handlers, .NET references, and so forth. Then when you want to code, you just open the template, edit the namespace (which might be automatic) and your good to go.

You may try Resharper.
Other option - you can try Telerik's Just Code.

I learned the dvorak keyboard layout, which is much faster for English and a little bit faster for programming. It took me three months to get back to my old qwerty speed, but I continued improving. I think it saved me a lot of time in the long run.

In addition to Resharper, I've found Hawkeye saves me enormous amounts of time tracking down source code for a particular widget, or trying out properties and their visual effects in real time. Highly recommended.
It's kind of like FireBug for .NET rich clients.

Read Zain Naboulsi's excellent "Coding Faster: Visual Studio Tips & Tricks".

Implementing a fully-functional prototype for a web-based application

I am building a prototype for a web-based application and was considering building the front-end in HTML, which can then be reused later for the actual application. I had done a Flash-based prototype earlier, which embedded the .swf into a C# executable. Flash made for rapid turnaround time while the Windows application provided unlimited access to fancy API's for DB access and sound.
I want to consider something similar for this one too. Does this approach make sense? I am particularly concerned about the way the HTML would communicate with the container app. From what I understand out of preliminary research, it would be only through JavaScript, which might quickly get unwieldy. This is especially so because unlike the Flash-based prototype which implemented a lot of its functionality in the .swf, the HTML UI will depend entirely upon the shell to maintain state. Also, I don't need anything more than access to a database. So a desktop application might be overkill.
Another alternative that comes to mind is to build the prototype using PHP and deploy it with a portable server stack such as Server2Go or XAMPP. But I've never done something like this before. Anybody here shed some light on drawbacks of this approach?
The key requirement is rapid iterations of the UI, reusable front-end code and simplified deployment without any installations or configuration.

Some of the best programming advice I've seen came from Code Complete, and was along the lines of, "evolutionary prototypes are fine things, and throwaway prototypes are fine things, but you run into trouble when you try to make one from the other." That is, know which type of prototype you're developing, and respect it. If you're developing a throwaway prototype, don't permit yourself to use any of it, however tempting it may be, in the production system. And if you're developing an evolutionary prototype - one intended to become the production system - don't compromise quality in any way.
It sounds like you're trying to get both, the rapid development of a throwaway and the reusability of an evolutionary prototype - and you can't. Make up your mind, and stand by it. You can't have your cake and eat it, too.

I think you off to the wrong start, here. Why would you want your prototype to be fully functional? A prototype is intended to be throw-away and to help flesh out requirements and UI. If you need full functionality, why not just skip to the final product? If prototyping is really something you want to do, I suggest looking into a specialized prototyping tool.

Are you prototyping the user interface for a customer? If you are, consider something less unwieldy like paper prototypes or presentation software (like PowerPoint) until you get the UI nailed down. If you can establish the UI and are clear about the customer's requirements, you can then develop the application in whatever the actual platform is going to be with a clear model in mind.
In my current project, I prototyped the UI in PowerPoint first. In a subsequent iteration, I used static web pages and some jQuery plugins to simulate actual user interaction. That proved to be very effective in demonstrating the interface, and I didn't have to build the application first.

I would join in on folks suggesting paper prototyping as the "idea", but not necessarily the implementation. The biggest point here is that tools such as HTML or Flash let you get "bogged down" in the details - what does this color look like? What's the text on this thing? Lots of time can pass by that way. Instead, what you should be focusing on is user flows.
One tool that keeps the spirit of paper prototyping without all the "paper" drawbacks is Balsamiq: http://www.balsamiq.com/demos/mockups/Mockups.html. It was covered by Jeff and Joel in one of the Stack Overflow podcasts; I've been using it for my own projects for a while. It's freeware, and it does its job magnificently.

If you know C# then another option you can look at is Silverlight. You can then leverage your knowledge of C# and/or JavaScript and interact with a rich object model.
Would that do what you are looking for? The installation would be minimal on the part of the client - download and install the Silverlight plugin

If prototyping is something you truly wish to accomplish here, paper and pencil will be your best friends. You can draw out as many iterations as necessary. While none of this is ultimately useful later on once you begin coding, it is as quick and rapid is it goes.
As mentioned previously, there are many prototyping tools which have a bit of a learning curve, but an alternative to consider would be using a framework such as CakePHP or Ruby on Rails which make for fast application logic and leave customizing the front end being the primary hard work left. And plus, you're left with a mostly functional application when you're done with your prototyping which can be tweaked as needed.
In either scenario, you're paying with your time either upfront (in the case with learning a new framework), of over time in payments (with the case of prototyping on paper or coding by hand).