Tagged: Software Planning Toggle Comment Threads | Keyboard Shortcuts

  • kmitov 4:19 pm on June 13, 2021 Permalink |
    Tags: , , Software Planning,   

    Dependencies – one more variable adding to the “cost of the code” 

    One thing I have to explain a lot is what are the costs of software development. Why are things taking so long? Why is there any needed for maintenance and support? Why are developers spending significant amount of their time looking over the existing code base and why we can not just add the next and the next feature?

    Today I have an example of this – and these are “dependencies”.

    The goal of this article is to give people more understanding on how the “tech works.”. I’ve seen that every line of code and every dependency that we add to a project will inevitably result in further costs down the road so we should really keep free of unnecessary dependencies and features.

    Daily builds

    Many contemporary professional software projects have a daily build. This means that every day at least once the project is “built” from zero, all the tests are run and we automatically validate that the customers could use it.

    Weekly dependencies updates

    Every software project depends on libraries that implement common functionality and features. Having few dependencies is healthy for the project, but having no dependencies and implementing everything on your own is just not viable in today’s world.

    These libraries and frameworks that we depend on also regularly release new versions.

    My general rule that I follow in every project is that we check for new versions of the dependencies every Wednesday at around 08:00 in the morning. We check for new dependencies, we download them, we build the project and we run the specs/tests. If the tests fail this means that the new dependencies that we’ve downloaded have somehow changed the behavior of the project.

    Dependencies change

    Most of the time dependencies are changed in a way that does not break any of the functionality of your project. This week was not such a week. A new dependency came along and it broke a few of the projects.

    The problem came from a change in two dependencies:

    Fetching websocket-driver 0.7.5 (was 0.7.4)
    Fetching mustache-js-rails (was 4.1.0)
    Installing mustache-js-rails (was 4.1.0)
    Installing websocket-driver 0.7.5 (was 0.7.4) with native extensions

    We have installed new versions of two of the dependencies “websocket-driver” and “mustache-js-rails’

    These two dependencies broke the builds.

    Why should we keep up to date

    Now out of the blue we should resolve this problem. This takes time. Sometimes it is 5 minutes. Sometimes it could be an hour or two. If we don’t do it, it will probably result in more time at a later stage. As the change is new in ‘mustache-js-rails’ we have the chance to get in touch with the developers of the library and resolve the issue while it is fresh for them and they are still “in the context” of what they were doing.

    Given the large number of dependencies that each software project has there is a constant need to keep up to date with new recent versions of your dependencies.

    What if we don’t keep up to date?

    I have one such platform. We decided 6-7 years ago not to invest any further in it. It is still working but it is completely out of date. Any new development will cost the same as basically developing the platform as brand new. That’s the drawback of not keeping up to date. And it happens even with larger systems on a state level with the famous search for COBOL developers because a state did not invest in keeping their platform up to date for some 30+ years.

  • kmitov 10:02 am on December 31, 2018 Permalink |
    Tags: , Software Planning, Trello   

    How to plan with Trello? Part 1 – backlog and sprint board 

    I recently shared this with a friend that is constantly getting lost with Trello and how exactly to structure his software project plan. I shared my experience with him and he kind of liked it so here is my story and the few rules that are keeping me sane for the past 2 years of following them.

    Main issues with planing a software project with Trello is to decide

    • are different features in different board,
    • why do you need lables. Are different features marked with labels
    • are different features in lists?
    • how do you set the priority for a task. Do you have a list for priority, or label for priority.

    Because of these questions for the last 4-5-6 years I’ve started and stopped using Trello many times.

    These are all difficult questions. Here are my simple solutions.


    Create two boards. Backlog and SprintXX. In the SprintXX you have three lists. XX is the number of the sprint. “SPXX Planned“, “Ongoing“, “Done SPXX December 01- December 15“. When the sprint that is two – three weeks finishes you archive “Done SPXX December 01- December 15” and create a new “Done SPXX+1 December 16-December 31” list. Then you rename list “SPXX Planned” to “SPXX+1 Planned” where XX is the number of the Sprint.

    This keeps the Trello clear.

    Create two boards

    Board one is the Sprint board
    Board two is the Backlog board

    If you are currently not working on the task and there is little to no chance to work on it in the next 3-4 weeks that it is in the Backlog. This means it will be handled later.

    Sprint Board

    The Sprint board has the name of the current Sprint. I like sprints that are 2-3 weeks long. It has three lists

    SPXX Planed

    The list has all the tasks that are planned for the current sprint or probably the next one. These are tasks that you are genuinely planning to do something about.


    These are all the tasks that we are currently working on. If we have even a single line of code for this task than we are working on it.

    Done SPXX December 01 – December 15

    These are all the tasks completed in the spring XX. Note that the list has the name “Done SPXX December 01 – December 15”. This is the full name of the sprint.

    At the end of the sprint

    When the spring ends you archive “Done SPXX December 01 -December 15”. You do not archive the tasks. You archive the whole list. This gives you a chance to get back to the list at the regular reviews that you are having with the team and actually review what has happened in this sprint.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc