High Level Design for Installation and Upgrade Application

Question

I need to write a very simple WinForms application, but I often get stuck in over analytical mode with these. I get stuck on Yes, No, Retry loops, and with very little thinking to do about the actions of the application, I start thinking about the 'workflow' of the application. Should I just have a method for each task, and call each one sequentially, after checking that the previous didn't raise an 'abort' flag?

Should I implement a simple ITask interface, and a class for each task, then loop through an ordered collection of tasks? Should I use this as a simple introduction to Windows Workflow? The scope of this application and its set of tasks is guaranteed to grow, so my first option of hard coding the tasks is the nastiest, but given the size of the app, maintenance can quite easily be done by just changing the code; the executable is always deployed with the upgrade materials, and not permanently deployed.

Answer 1

Do the simplest thing. You can always refactor later.

Answer 2

I'm going to add to Peter's suggestion by saying, "Do the simplest thing could possibly work that is also good design".

There are times when the "simplest" thing is also the dumbest thing, from a design standpoint, and it will cause grief down the road, which is the opposite of what the Extremem Programming mantra is after.

Your second option sounds right to me. It is simple to implement, a good design and will facilitate maintenance later.

Answer 3

On workflow foundation, I would keep it to advanced scenarios/projects, where you will use a lot of it, like highly customizable workflow that you want to vary per user/company, complex workflows needs, pause/continue.

I would go the ITask route for its flexibility (vs. simple methods), while still simple at the same time. I feel it will also help you with the unit/integration tests. That said I recommend to keep an eye on reuse of tasks, like say a file move task, as you don't want to end with tons of tasks that do the same. Just do it on the refactoring steps, so you let the actual needs/use dictate what you need (in tests - TDD :)).