How to communicate, think, plan, design, programme and code BY JOHN JAN POPOVIC

My thoughts on Coding Methodologies
-------------------------------------------------------
REFINEMENT OF THE PRODUCT REQUIREMENTS
------------------------------------------------------
“The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.”
—Fred Brooks

-----------------------------
DATA AT THE BEGINNING
-----------------------------
At the beginning I am focused on data repositories, all files in the system, and their data records structure. And what must be done in order to process input files into desired output behaviour and data. What are the test scenarios, and if the customer has provided test data together with requirements?

-------------------------------
GENERAL SPECIFICATIONS
-------------------------------
In this early stage it is clear :
- what are the files in the system repository, and what is their record structure
- what is desired behaviour of the software modules and objects
- feature specification list
- test data and test scenarios / input and desired output
Customer must be aware that in general lines, the software requirements should be set in stone before Development CYCLUS begins, in order not to wasted work put into a design and development based on incorrect requirements.

---------------------------------------------------------------------------------
ROADMAP DEVELOPMENT PLANNING, TRACKING AND THE TRADE OFFS
---------------------------------------------------------------------------------
The primary planning task is providing recommended short term, intermediate, and long term strategic goals, and lay out MILESTONE objectives.
This ROADMAP includes implementation milestones, cycles phases, schedules, potential costs, etc. for the activities which should ensure harmonization with the customer plans and successful implementation and deployment of milestones.

-------------------------
ROADMAP REVISIONS
-------------------------
If desired, the order of the MILESTONES can even be altered to suit the particular needs of the planning team. The implementation step also does not end the planning process. Analysis of results could easily result in additional analysis or a change in strategic direction. Also, it is recommended that the plan be reviewed periodically, sometimes even on a daily basis in order to verify that all the base assumptions are still valid and that the implementation plan is progressing according to expectations.

The secondary planning task is providing alternatives, trade-offs, and constraints in implementing a scalable performance-based system. To buy, to built, to outsource or rent the service or solution. THAT IS THE QUESTION?
.
implementation of improvements in the... planning support that includes Operations Evolution -- safety, policy, procedures,...

------------------
METHODOLOGY
------------------
FDD Process is applied for the development of an Overall Model > For 0.1 alfa verson of the software I will start by creating really elementary application, with some simple and already well understood features by reusing previously developed code. And I will try to implement all Data Stuctures relevant for the system repositories, upon which the new features will be developed and deployed in the future.
From the customer wish-list, formal requirements specification will be produced; which will evolve into features list. Then a rough plan is drawn up and responsibilities assigned. Now we are ready to repeatedly take small groups of features through a design and build iteration that lasts from several hours up to couple of weeks in rare cases.
.
For some difficult features I apply a TDD - test driven development methodology. I go forward in small incremental steps, create a Simple Test Case scenario, implement a little code at the time and figure out how I can test it if it is correct; create more difficult Test case and reiterate that process until I have a strong and robust Error reporting system with possible corrective patterns. The point is that you try to see what could go wrong if you insert incorrect input parameters, and if it will be correctly reported or just ignored, or if the system will crush. When I am sure that this feature works fine, and fails gracefully and reports the error correctly; I clean up the code and comment it.

My approach is adaptable, allowing me to engage and provide testable solutions at any stage in the software development life-cycle. From planning and pre-definition strategy to post-release usability. I blend a variety of methods and best practices. This allows me to create valuable and testable solutions in every stage of the development.
.
What I really do not like is Big Design Up Front (BDUF) development approach in which the software design must be completed and perfected before the coding starts. It is often associated with the Waterfall Model. Big Design Up Front (BDUF) is a term for any software development approach in which the program's design is to be completed and perfected before that program's implementation is started. It is often associated with the waterfall model of software development.

Otherwise my design at the beginning is often vague and general, for not having the clear picture, and since often the problem assignment is not well defined in advance by the customer. Often at the beginning, only what I have is only a vague impression of the assignment versus a precise one customer is not able to provide.