How to Start
Just start coding….get right in there and slap some nasty code around…NOOOOOOO!!!!
The worst thing you can do is to start climbing up a cliff without looking for all your potential footholdings, so why would you do it when developing an application. You need to scout out the path and plan accordingly. Meetings to the rescue!!! We all love meetings right? Well this meeting might be the most useful and fulfilling one you’ve ever been a part of….the Discovery Meeting.
Best plans are ones that have a good view of everything. So you can do this by performing a discovery meeting. Get together with the “powers that be”, usually the customer. Then determing 1)what is their intent and 2)what is it they want to achieve.
Likely if you have done any professional development work in the past, you’ve been asked to do some feature enhancement; for instance “Make the banner red and flash when you mouse-over it.” or “Process all the records in the database and transfer the values over to the new reporting table.”.
What Do They Want?
You can save yourself a lot of back-and-forth if you start by finding out, what do they really want. For instance, if they told you to “make the banner bigger and flash”, your initial reaction should include questions like why did they want this? It’s likely to get the users attention, but is there a better way. By just jumping in and coding you may find yourself in the iconic situation seen in the following visual…
How Does the Meeting Work?
In the discovery meeting you should at minimum do two things:
- Figure out what the customer is trying to achieve
- Confirm that you understand their vision
Don’t rush this. You can do this by providing a prototype, and when you do you should adamantly and constantly describe it as a prototype for demonstration purposes only. Prototypes should not be used as part of the final product, but should show the customer how the eventual feature will accomplish their need(s). This “meeting” might actually be several meetings, stretched over days, but getting the ambiguity and uncertainties cleared up at the start will make for a much better and extensible design for the future.
Now What (Post-Discovery Meeting)?
So lets say you did a great job and discovered what your customer needs and made sure they liked the prototype. As you did this, did you document all the information you were gathering? This documented information should be put together into a “contract”. This “contract” document is known as a Functional Requirement, and it is a contract between you and what you are telling the customer you will be providing to them functionally. This should also be seen the other-way-around, a contract from the customer to you stating they agreed to these functional enhancements. Many times we find ourselves at an end of a project just to be told by a customer, “Boy, I like it, but can you make it do <x>”. This keeps us from running into a concept known as Feature Creep, don’t let it happen to you. Before continuing you should avoid the urge to just start coding. We need a strong design. But what kind, you got some major paradigms to choose from; procedural, object-oriented, and functional to name a few.
So how do you do this in an object-oriented way?
Just because object-oriented is an old paradigm, doesn’t mean it is easy or that it isn’t useful. There was a reason it became so popular and still produces strong commercially used language frameworks to utilize its capabilities. One of the biggest advantages to using this paradigm is it makes it easy to mimic the “real-world” in software design, which makes it very easy to understand and extend if properly designed. Does this mean you should always use object-oriented design? No, it is just a tool that needs to be used when it is right. You wouldn’t use a hammer to screw in a screw…well I guess you could, but it would be really nasty and hard…I wouldn’t do it.
Lets go back to the discovery meeting. As you were planning out the work with the customer and demonstrating your prototype (remember that thing is gonna get thrown away….don’t use it), how could you represent the pieces in a “real-world” object way? As you think about each piece, you should start jotting down these “potential” objects. I say “potential”, because what generally happens is we choose something to be an object and BAMM it is actually just a data structure and should not had any methods, but now you created this weird entity that shouldn’t exist….you mad scientist you. So, as you make your list you must think what are these things? Are they really objects? So now that you have your list of all these “real-world” entities, now you need to think can they hold data and do something….yup that is what it means to be an object, it needs BOTH!!! What if it just has data…that is a Struct. What if it just does stuff…that is a function (global, namespaced, wherever you have it).
We’ll get back to it in (Part 2)….