+972 52-548-6969
Development stats
time to read 1 min | 182 words
A single page.
- 34 integration tests.
- 432 lines of test code (excluding data setup and stuff move to test infrastructure).
- 66 lines of code behind
- 210 lines of Javascript
- 641 lines of in the ASPX file (include the javascript above)
- 221 lines of code in the the controller
A lot of time.
Excluding the ASPX stuff (which include extenders and other things I probably shouldn't exclude), this puts me at 497 (210 of which are javascript) lines of code vs. 432 lines of test. It is simply amazing how much time the UI can take. And how its demands can drive the rest of the system.
Comments
I used to tell my junior devs that they should not think coding a pleasant UI is one of the easiest parts of the project. And that's because the "U" has a historic tendency to break and bitch about the "I"
Would you say the amount of code is more or less for UI using MonoRail or some other MVP architecture versus the traditional WebForms?
WebForm code behind files are notorious for becoming insanely long. I've seen 2K lines in a code behind file WAY too often.
I am using Igloo, so it drastically cuts the amount of code that I need to handle.
If you have a lot of code in your code behind, then you are usually mixing concerns together, both business logic (controler) and presentation (view).
Consider the complexity of the external interfaces with which a UI must interact: People. Designing for users is much harder than designing for a given platform or system architecture. Consider that your application must be "portable" across a vast number of users' eyes, ears and brains whose runtime behavior is complex and ill-defined. It sure makes a CPU or database look simple by comparison.
The complexity of UI interactions will generally dwarf what's going on in the core code. This is particularly true if you consider all aspects of UI including the documentation, the usage conventions, the graphics design, the affordances, the controls, the shortcuts, the integration with other apps, the error diagnostics, the packaging, the training, the marketing, the installer, the maintenance, etc...
In my experience UI concerns are often dramatically underspecified relative to the rest of the system and much behavior is left up to common convention or individual judgement. I've seen junior coders be frequently surprised when the "little details" and "finishing touches" end up taking more time than the larger strokes of the design did. This is particularly true when the feature team lacks a designer, an artist, a writer, or a representative user. Coders are notoriously bad at the tasks performed by these specialists.
Comment preview