Best way to design and plan a winforms project? RRS feed

  • Question

  • I could use some advice and suggestions, possibly some tools and software that will help design complex winforms. The problem is my client is not a programmer, but loads up Visual Studio and make changes or he designs the forms and tells me to hook up the code to make them functional. We're dealing with 100's on controls on a form, and I really don't agree with him on how he designs the forms -- they aren't very usable and require constant changes.

    Here's our development cycle:

    1. Client gives me changes he wants made.
    2. I keep track of these "tasks" and prioritize them.
    3. I make the changes and release a new version once or twice a week.

    The problem is I don't know how to convince my client there needs to be a spec which we don't really have -- a longer term scope and a development cycle to include design, prototyping, testing, feedback, etc. I don't know how to make my case. He says things like "the walls need painted, I paint them, it gets done!"

    My client does not know how to come up with a form with all the fields he needs. He would rather get something started and working and then constantly tweak it and change it, even adding and removing fields which require database changes. One day we'll use a drop down list and then the next day we'll remove the drop down list and replace it with a look up table.

    So if anyone can give me some suggestions, and possibly suggest some tools we could try in order to get our forms designed more fully and our project on track?

    Wednesday, January 2, 2008 3:51 PM

All replies

  • I think the happy medium lies somewhere between your point of view and the clients. You seem to be into the big design up front, while your client is agile but not much of a team player. The way that the client is designing the forms needs to be addressed. He can mock up forms but you should be applying these changes to the actual forms (is the client actually working in the real code?). You can then address your concerns about how usable the forms are and apply the changes using a balance of ideas.


    If you feel that you need to apply some more discipline to the project then you need to show the client why your way is the better way. In reply to his comment about the painting, I would have replied using metaphors, i.e. "do you put down a drop cloth before you paint?". This way you are rationalizing why for example you need to be writing tests.

    Thursday, January 3, 2008 1:17 AM
  • First point is, you are not painting a wall.. but building one. So if you are going to change it no of times it is going to get weak.


    Also let your client know that UI is only one of the requirements(Even if heis going to provide it in "Agile" fashion). You need Use cases and reports to design a system.


    Once you get these, document them and apply version control. Each change he makes to these documents its going to take more time than building it for the first time, because your functionalities will change, your design will change and your code will change.



    Educate your client on this.


    And from your side don't think you can only develop your software only if you get all your requirements upfront..Its never going to happen.



    Thursday, January 3, 2008 8:53 AM
  • Hi


    How about using a change/bugtracking system? There you'd have all change requests together so you'd be well organized and have something to show your client when he asks you why this and that task took so long. Another advantage is that you do not have to deal with all those E-Mails.


    I'm using mantis for this purpose. Its free, open source and easy to use and install.



    Thursday, January 3, 2008 11:47 AM