When I first started at the county, I would be called into an office. Someone would say “write a program to do the following…”. I would type up my notes, confirm the request and start coding. I’d post the program on some server and people would use it.
Then management changed. Management created a Dev, test, and production servers and added additional instructions. “Post to Dev and test it. Then post to Test and have the customer test it. When customers have finished testing, then post to production.”
Then management added a code repository, and added more instructions. “For each program. Make sure there is a develop branch, a test branch, and a main branch. Keep the branches aligned with the code on the servers. “
Then they gave us Jira a program to keep track of tasks, and added more instructions. “Each task, should be treated as a separate coding task. A task has a few status codes: new. In progress, in testing, ready to deploy, closed(there’s a few others as well). You musk keep the ticket status in sync with your progress on the coding, through to delivery.
Later “create a code repository branch for each ticket. Create a pull request to have someone review the code changes, give them a day to review, then merge the changes into the develop branch”
Then more instructions. “You do not have programming access to the test or production database. Rather you create a ticket for the dba to change those databases. You must also coordinate the release of an update with your customers, preferably release on Wed evening or Wed afternoon”
Each of the added tasks are fairly simply. But here’s what it looks like if you arranged the work into a checklist.
- Changes Jira ticket from “new” to “in progress”
- Create a branch.
- On your programming editor, change to the new branch
- 1: Do your programming changes.
- Test your code changes locally.
- Commit / push / create code review
- Merge to develop
- Deploy to development web server
- Test on development server
- Create pull request from develop to test branch
- Merge to test
- Submit dB change request (if necessary) to update test database
- Post to Test web server
- Test Test website
- Change Jira status from in progress to in testing
- Update documentation.
- Notify uat team to start testing changes
- If problems found. Return status to in progress, return to step 1:
- When testing is complete, change status to ready to deploy
- Schedule a release time
- Create pull request from test to main branch
- Submit and schedule a dB change request (if nessesary) to update production data base
- Merge to production
- At release time, update website and data base.
- Quick safe smoke test
- Close Jira ticket
Wow that’s a lot of work to do with fit one programming assignment! Realistically it is probably right, but maybe I spent a lot of my career taking shortcuts, maybe shortcuts on shortcuts.
But As you can see, making a simple change takes a lot of work. The items in bold were what I used to do (maybe a few more should be bold)
This bullet list is typical and possibly realistic of the steps you need to do of you are a programmer working in the kind of environment I work in (which I perceive to be fairly typical)
And this list of steps is the same (except for the do your programming changes) each time you make a change to an application. Generally, you learn the above process, but it’s petty brittle and mistakes happen.
What I do, is for each task assigned to me. I will copy the bullet list (above or at least a similar one) into a document associated with this task. Then, I’ll mark off bullets as they are done. (Usually with a date and the word ‘done’ or ‘skipped’ next to each task bullet) this is a good place to add other non essential data and additional reminders as well. Most items only take a moment but it’s easy to get distracted and to lose your place, and then mistakes start. Working the checklists have forced me to work the process in the same order and I have found it to help produce quality results.
For me, for now. This is the basic task list for a programming ticket. Over time a new requirements are added and dropped. The list will grow or shrink.
I am not proposing you use the above checklist. I am suggesting that you assemble a generalized checklist for the common tasks you preform and then attempt to stick with it in a consistent manner with each task you preform.
In theory.. A business analyst will review this checklist. Probably come up with a procedure guide. The procedure guide is good, because it gives instructions to the newbie. But for me as long as the check list matches to the procedure guide, I find more utility in the checklist.
Pro’s of a copy of the checklist per task
- You keep track of where you are in each task
- You can add reminders to the checklist more easily
- If you are interupted a log, this will reduce the chances of a mistake when you finally get back to the task you are working on.
Con’s
- Appears Excessive?
Computerization of the checklist.
So far I’ve made 2 attempts
The data dictionary
- The data dictionary has a task management system, and for each task there is a primitive subtask system. It has a function to load from a template so I can pick programmer task and it would drop in 20-25 subtasks. When you were done with a subtasks, when you check it off. It gets removed from the list and added to the task notes.
- The program had one major flaw, while you could add additional subtasks. You couldn’t sort the new subtask to where you needed it to be
The Word document
When the office switched to Jira, I lost the subtask capability and moved to a Word document.
This is what I am doing currently. I have a giant Word document. When I start a Jira task I add a task number, and then a copy of the checklist. When I eventually get back to this task I go to the location in the Word document, and continue on that task’ checklist
One big advantages are I can add notes to an item on a checklist and I can easily add additional items to the list.