4

This is a problem that has happened a few times in the last year. I will code something, spend hours doing it, get 100% code coverage, then find out it wasn't exactly what my employer wanted.

There have been times when its my fault because I didn't understand something clearly, and other times because my employer doesn't understand fully how his problem can/can't be solved by the way he thinks the code will work.

When I get the specs to code something, it's in an email, work chat, or via a text. What I've decided to do is before I start coding, create my own doc and share it with him, to make sure we are on the same page.

Here is an example of what I've tried to create, but it just seems messy.

enter image description here

Does anyone have a template or advice on how to write greats specs before you code?

  • I guess I basically asked the same thing here. – Adrian Larson Jun 14 '17 at 0:03
  • I've got some ideas for a template style for this that I might be able to work up into something useful, but that will need a few days. I'd be interested to see others ideas too. – Dave Humm Jun 14 '17 at 10:04
  • Quick proofs of concepts can help confirm you are taking the right direction as well, use them to give the stake holders a play back and something to touch and feel. – Girbot Jun 16 '17 at 18:18
  • 2
    It would be helpful to know WHAT you get from your employer in order to respond to your question. If you're getting an Agile User Story, then you're translating that story to design requirements. If you're being given design requirements without the solution being specified, that's another situation. At times, solutions are either iterative or clients aren't clear on exactly what they want; yet often don't recognize it until they see & use what they've described working in an org. This is normal. – crmprogdev Jun 17 '17 at 12:53
3

Honestly, I think that your question only looks similar to the one that @AdrianLarson linked because your design document looks like documentation.

I also think that that's where your problem lies.

If you need to confirm the desired behavior of your system before implementing it, the document you are writing shouldn't include any code, it should only focus on the behavior that the system will exhibit.

I would do something like this:


  1. Triggers

Opportunity:

  • whenever an opportunity is saved, update the value of Territory__c to be the same as the value of Territory__c on the associated shipping address.

  • whenever an opportunity is saved, update the owner of the opportunity based on the owner of the territory

Note that we will not be able to directly edit the territory or owner of an opportunity. An opportunity with a linked shipping address must use the values on the associated shipping address and territory.

Territory:

  • whenever a territory is reassigned to a different owner, reassign the linked opportunities to the new owner

Note, this will automatically reassign all opportunity ownership for that territory, regardless of sales stage. All opportunities from Prospecting to Closed Won will be given to the new owner.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .