I'm new to programming and I'm trying to develop a template of questions I can apply to business rules that will help me extract what's needed to begin coding.

Do programmers have a set of questions they ask themselves or any kind of template they use to assist in this process?

Example rule:

Business Rule 2: There must be at least two weeks of paid time between assignments.If at least two weeks are not selected between the previous assignment and the new assignment display an error message. Show the manager the earliest available date on the calendar by selecting and showing that date in the "Start of New Date" Calendar.

I didn't know exactly how to translate this into code. I have the answer (from a Bob Tabor Course), but to go from that rule, to this code, I have to ask myself deeper questions that I was because I didn't get this code from that business rule.

        TimeSpan timeBetweenAssignment = newCalendar.SelectedDate.Subtract(previousCalendar.SelectedDate);

        if (timeBetweenAssignment.TotalDays < 14)
            resultLabel.Text = "Error:  Must allow at least two weeks between " + "previous assignment and new assignment.";

            DateTime earliestNewAssignmentDate = previousCalendar.SelectedDate.AddDays(14);

            newCalendar.SelectedDate = earliestNewAssignmentDate;
            newCalendar.VisibleDate = earliestNewAssignmentDate;                

So far based on a question I've asked recently, I've come up with a few questions, but I wanted to know how professionals go from rule to code, and if there are any tips/tricks to help one think deeply enough to extract what code is needed.

Thanks for helping me!

  • 1
    Is the code you provided the author's solution or is it your own answer? The first thing I notice is the coupling between the business logic and the presentation logic, which is not a good thing. – Vincent Savard Feb 9 '17 at 16:12
  • @VincentSavard I think the OP is a bit too young on programming to start tackling coupling right away. This is a somewhat abstract concept that you need time to understand, and if you don't really get the basic parts of programing - the language building blocks - you'll surely have a hard time to grasp. – T. Sar - Reinstate Monica Feb 9 '17 at 16:15
  • It's not exactly clear what level is OP (I personally had to clue what business logic was when I started programming), but I definitely believe coupling is something to keep in mind when you start reasoning in terms of business logic, because the core of business logic is a good architecture that will evolve gracefully. – Vincent Savard Feb 9 '17 at 16:18
  • @VincentSavard Coupling is a high-level, OO concept that is incredibly important. Good coupling is a consequence of skill and experience - unless he understands fully what he is doing with the language, he won't have any chance to grasp things like interfaces and abstractions. – T. Sar - Reinstate Monica Feb 9 '17 at 16:25
  • We're drifting on the off-topic side here, but coupling is not an OO concept, and to the question "How to translate business requirements logic into code", part of the answer is "consider coupling". If OP is not experienced enough to profit from this, then so be it, but I think answers should be general enough that they are not specifically tailored to the OP. – Vincent Savard Feb 9 '17 at 16:31

You have a lot of scattered Lego pieces and need to build a little car for one of your kids. You don't have a instruction manual for it. How do you do this?

You start by thinking what exactly are you trying to build. What is a car?

  • A car is a square-y thingy.
  • It can hold people inside it.
  • It has wheels.

Knowing this, you look at your Lego pieces, pick the ones that match your requirement or - missing those pieces - combine a few Lego's to get something that works for the thing you're building. Then, you look at your little misshapen car and see how ugly it is and how it could be made better.

Then you go on to refactor it - you remove a few stray pink blocks to make your car all red, you add a driver's seat and a little steering wheel, you add a few moving doors so that the minifig can "enter and leave" the car, etc.

You keep adding little details until your car looks somewhat like what your kid wanted.

It may look silly, but this Lego example isn't that different from programming. You get your problem, break it in requisites that you can work with, do a initial draft and them polish it until it looks like what your client wants. Only that, in our case, our Lego bricks are our APIs and Frameworks, and the connections between then are made using not that round plugs but our language of choice.

You start with a little piece of code that follow some of the rules that you need to satisfy, and then you start polishing your draft until it gets acceptable. You don't need to create a big, perfect code right from the first time you sit on your computer. You don't solve a jigsaw by matching every piece at once, but you do it one at a time.

In the end, we are all just glorified Lego-Builders.

Everything is Awesome!

  • To everyone that watched The Lego Movie and got the song stuck on your head because that last line, you're welcome. – T. Sar - Reinstate Monica Feb 9 '17 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.