2 ms·
Funny that you mention that the report writer becomes the person closest to understanding the business. In my experience, the report writer many times is the d
by OpenDrapery 10y ago
Funny that you mention that the report writer becomes the person closest to understanding the business.
In my experience, the report writer many times is the developer on the team who drew the short straw. So you get this weird effect where the best way to learn the domain is to end up with the least desirable project work (from a dev perspective).
- protomyth 10y agoI ran into a developer that was happy and proud that no report writer could generate a report of a transaction because he did all the calculation on the fly and couldn't be bothered to store some critical data in the database. He basically said that the report writer would have to duplicate the program logic in the stored procedure returning the report data. He was honestly happy and didn't think he needed to take the time to fix it. The report was a customer bill, no report, no money. Yeah, I get any project has tiers, but I have a special hatred for developers who dump on report writers or testers. The developers fancy achievement don't mean a damn thing unless we can get data out of it including billing. Sadly, a lot of the trouble results from a single rule: if a developer cares about the state of a single item when making decisions, be advised that some report writer is going to have to write a report that shows all of the items in the system with that state.