My answer to the challenge question is yes, there is a challenge. Understanding really well customer requirements is. What is the business process behind? What are the entities and properties?
What tables to I have as an input? Fields set as a flag? Certain situations require different treatment?
How much freedom has the user, to manipulate or corrupt data?
Yes, processing the real data that goes in the application is the real challenge, mapping it to entities that can survive the changes of the life of the application.
And what to do when the input data has some flaws? Data duplication, bad codification, violation of uniqueness... how to bridge this in my database?
Writing code is the easy part.
1. there is some routinely written code: SQL queries - 80% are repetitive, following the same pattern (not exactly same commands). Writing the entity classes and the ORM functions that map DB procedures to entities, almost totally a routine.
2. Some semi- routinely written code - linking the WPF layout with bindings to entities, setup the ViewModel and View, draw basic XAML (copy-paste, than change)... Oh how I hate this XAML.
3. The interesting part is to write some algorithmic functionality: saving files and creating emails, generating views with filtered data, writing some more complex LINQ queries, generating invoices, creating Outlook Emails, Reports with Reportviewer...
What is then the hard part?
I think understanding the requirements really well and mentally mapping out a process how to tackle the solution step by step. Visually, View by View, Tabs, Tables, Reports, and a general succession.
Then comes the execution, test, populate with data, correction, again test, again addition of data, etc.
And finally the customer feedback, and again, corrections, optimization, refactoring, test, submission to the customer.
And after several attempts, there is the prototype that can be used at least on the short term, before the next iteration.
That's my approach. What do you think, what's your process?
