The back end stuff is frequently harder to validate in quality assurance. It's possible that you don't know just how unstable the back end stuff is until after the front end is working perfectly.
Hopefully you've got some unit testing of the back end that doesn't require a front-end UI to test.
Our back end stuff is 95% covered by unit tests (only things that aren't are integration points such as web service calls and configuration wire up code like IoC bindings). We are a small team of two developers and both of us are big believers in TDD, so basically any code that contains logic is test driven.
Byond that, we have an application we wrote to test our basic processing engine by running it in multiple threads (the processing must be able to synchronize across multiple threads and machines for effeciency/high availability), throwing a ton of data at it, and verifying no processing collisions occur/exceptions are raised.
Finally, we have two full time QA who are dedicated to testing our stuff by looking at database records and mock data input and output.
Obviously we still have to make sure our stuff integrates well with the other team, but I'm very confident in the quality of what our code is doing. If issues do show up as the front end comes along, I think we'll be able to correct them fairly quickly.
To contrast, the UI team has something like 30% test coverage (and I probably wrote 30% of those tests before I was moved off to work on back end stuff). I realize that test coverage is easier/more benificial for back end, so I really am trying to be open minded and not pull the "if you just did things my way, you wouldn't be having all of these issues".
User Interface is more time consuming when you have complex business logic in my experience. GUIs can be easy if your program is simply displaying data and asking the user simple questions. But when it gets down to "user can click on this, but not if this is checked" or "you must validate this input based on this complex business logic" that tends to be more time consuming in my experience.
This is exactly the kind of stuff they ares struggling with. This app will be used by many different financial orginations, each with its own structure, so creating a UI that is easy to use but handles all the scenerios can be challenging indeed.
Then there's the whole GUI design aspect. Who is designing the GUI? Do they have a clear design when they start or are they making up the design (and changing it) as they go?
We do have a designer + 2 business analysts and the UI team is working off of wire frames, so there is clear direction. That being said, we are demoing changes every three weeks and obviously the customer is going to have input on what they see (even if they've agreed with the wire frames- once they actually see it it's a whole new ball game).
Of course this affects the front end WAY more than the back end (the users don't really care about back end stuff- it just has to work), but our pain point isn't customer satisfaction with work- it's that at the end of every iteration we have dozens of major defects that are causing us to push back demos, which obviously looks very bad to the customer.
Good programmers are not ever necessarily good UI designers. You need to have someone sit down with the users, or, preferably, an internal user proxy who understands the business needs well, and design a UI, without any regard to what the back end looks like.
When integrating the two, you may find inconsistencies, and while this might be a real problem, more often than not, it's a miscommunication between the users and the developers, and can actually help to find "real" issues.
Fortunatly, this application is a re-write of one that existed before (At another company). Unfortunatly, the actual UI coders were not involved in the previous project. Fortunatly, the BA and end user were, so they have a VERY clear concept of what they want (and what was a pain point in the UI before). By default, our goal is to keep the UI the same, but obviously a lot is changing, espcially since we have a designer who is making improvements to what we had before (some VERY good improvements).
Basically, the good thing is that developers are not really responsible for the layout/functionality of the UI. I pushed VERY hard at the beginning to get the designer added to the team, and I'm glad I did. It's a really good thing to have someone who is not a developer be responsible for the UI layout and behavior.
Previous Topic
Index
