Tag: The Business of Programming

In the previous post in this series, we talked about defining requirements (or a statement of work) and why it matters to have this.

Before we get into actually understanding – and writing – object-oriented code, there’s one more “business-related” topic to discuss: Terms and Conditions.

For many, it’s a bit of a dry topic, but if you’re looking to build solutions for someone else, do so from the ground-up, and do so properly, then it’s important to make sure you have all of the necessary pieces in place before doing so.

And once you’ve:

• performed analysis (part one and part two),
• understand your customer’s expectations,
• and have prepared a statement of work,

It’s time to make sure you have the terms under which you’re working.

Continue reading

Before we get into the topic of object-oriented analysis and design (which is when most of us get the most fun out of what we do aside from actually writing code), it’s important to follow-up a few more things regarding understanding customer requirements.

In the previous post, I mentioned:

If you take time to understand what they want from the beginning, then the requirements don’t have to be a 50-page document outlining how every single module has to work.

For example, whenever I put together requirements (or a Statement of Work) as I usually call them when I send them to clients, I rarely exceed ten pages, and it’s often less.

And though there are times when it’s longer, I think that part of the reason that developing a short set of requirements comes with the preliminary discussions to make sure you and the customer(s) have developed a common language with which you can work.

When you do that, the requirements and the statement of work – whatever you opt to call them – don’t have to be as long.

Continue reading