Software Dev - Planning
About
A page full of planning related things
We do not really have an accurate sense of time, but rather a pretty terrible perception of it. Consequently, guessing how much time a project might take - especially those ever-changing agile projects - is not significantly more accurate than predicting weather with a magic ball.
Articles Related
In carpentry, you measure twice and cut once. In software development, you never measure and make cuts until you run out of time.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
The true work does not reveal itself until you get into the code.
Je kunt over allerlei onderwerpen vragen stellen, ook over meditatie en spiritualiteit maar echte antwoorden komen pas als je iets zelf gaat ervaren.
Opportunistic actions are those in which the behavior takes advantage of circumstances. Rather than engage in extensive planning and analysis, we go about the day’s activities and do things as opportunities arise. Thus, we may not have planned to try a new café or to ask a question of a friend. Rather, we go through the day’s activities, and if we find ourselves near the café or encountering the friend, then we allow the opportunity to trigger the appropriate activity.
Deadline helps to fight wiki/procrastination. See
Procrastination takes place until the “last minute” before a deadline.
Adding manpower to a late software project makes it later
Make it correct, make it clear, make it concise, make it fast. In that order.
Toothpaste For Dinner Random Comics
See (Innovation|Creativity|Genius)
Drawing Spiderman in 10 Minutes, 1 Minute, 10 Seconds
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Whenever you ask an engineer “how long is this going to take and how much is it going to cost?”, remember the @ossicvr Kickstarter raised ~27x its goal and still failed
Planning is architecture dependent
The varchar table
- Data Conversion and validation not done has first step. The validation and transformation need then to be:
- describes two times in the specifications
- done in two places
Refactoring is too risky without test automation and always seen as a task that will kill the planning.
This is an example of technical debt.
What is never planned but must be done
- Environment installation (Locale installation)
- Code base knowledge (Where is the log, where are the configuration files, where is the main, …)
- Code shipping knowledge (How do I release my changes)
- Test knowledge (How do I test it)
- Test case knowledge (Do they exist ?)
- Bug resolution:
- Basic test case doesn't work with my data, why ?
- No knowledge of stack trace by default (PL/SQL)
- Spend a day debugging a dev environment
- Language knowledge
- IDE knowledge:
- No completion
- No navigation
- No debugger
- Library knowledge (This library returns “Unable to connect to the host”. Why ?
- Bad parameter: Hostname, Port, Proxy, Certificate path)
- Bad network configuration
- Infrastructure knowledge (I need to call a server but I didn't get a connection on the server)
- Specification knowledge:
- Adding a column change the business flow and therefore one or more functions
- What if things goes wrong ?
- How does we give feedback on what happens ?
- No Concurrent development architecture in place. (Lock between members of the team)
- Avoid features that takes into account future business logic in case of. Example: An order type will say if the customer must be contacted but the functional want to add a configuration column because in the future, this may change. State is hard, code is easy. (alter table, default value or error if not found, …)
- Why not test on a acceptation environment ? During the first test, there is always new insights on the behavior of the system. For instance, I have asked it so but I see that it's not working because of this logic.
History of a straightforward project
- No dev available that knows the language and the application
- The spec are just a couple of line in an excel sheet (No unit test)
- The connection didn't work because the certificate were expired
- The library respond always with the same message when a fault occurs: No connection to host
- The project doesn't start because the project manager refuse to start without clear functional spec
- The project was still planned and signed by the customer
- The development pipeline was written for only one dev. There was already a deliverable ahead waiting a configuration file.
- Dev was done on the server
- A local environment must then be installed with a branch
- The project manager asks a commitment to the assigned dev who refused and get send home
- Acceptation: The acceptation person had a bad proxy parameters in SOAP UI (two days because the message was written as it was a DNS fault)
- No connection to the external website to check the result of the SOAP call
- We got it but they send us an internal URL
- Not possible to test against the production SOAP system.
- Bug in the language:
- The socket timeout was not acknowledge
- The new version has a false test on the existence of the host
- The only test environment is an acceptation test where only the ops can release them. It must be taken into account in their planning
- One modification is not for the WebService but for others clients. How can we test it ?
- The functional spec requires to select an external table that the user doesn't have access to.
- The log library doesn't have any notion of LOG_LEVEL.
- An email must be send. As the application is written in two languages, there is not two places but three. One from a global settings file, one from a table and one from PLSQL.
- Only the happy path was described. I got an error. Where can I see it ? There was two logs. I got two errors.
- Configuration not found → fault was describe but not when the configuration data were not good.
- The app was triggered through a third party scheduler and was stopped
- The code after branching was not working. The previous developer has checked in non functional code just to backup it.
- The proxy function was based on the fact that the user has the environment variable. No true, it could for any reason lost it
- The proxy didn't let the call goes through. The network sysadmin had to be called.
- The test was planned on the dev env because the dev team didn't have receive any acceptation criteria and that an other delivery was still in acceptation phase in the acceptation server.
- As the acceptation phase took place on the dev env, it appears that the acceptant didn't had any permissions to connect to the server.
- The acceptant got a DNS error. We thought for a couple of day that it was the permission but it was due to local proxy parameters on the software itself (Soap UI)
- On the dev environment, it was not possible to send email to the domain
- The project manager was gone on vacations
- The scheduler was starting the application even if the previous instance was not done through soap timeout problem.