Comment by lucaminudel | Hacker News Reader

Comment by lucaminudel | Hacker News Reader

Really interesting report I begin with questions to understand more teams context and to get to know other aspects that are interesting to me.

1) How often teams released in each of the 4 years

2) What is the state of the code-base (i.e. how many parts of the code devs would prefer not to work with, how many bugs are discovered only in production, what is the CC, what is the size of the longest method/class, how many conditionals and static members are in the code, how much time it take for a new team member to do it's first check-in)

3) What about collective code ownership ?

4) How many time you discovered/learned things only after releasing a feature and how are you dealing with that now

5) How much unknowns, uncertainties, unexpected-unpredictable events and changes there are in your domain and business and how you deal with them

6) What about devops and support and operation of the system in production?

7) what about the features released, how much they are the right features for the users and for the stakeholders ? how much early the team spot the wrong feature?

Wow, thank you for so many questions :)

1) How often teams released in each of the 4 years

We release new builds every other week. Sometimes more often, sometimes less often, but on average every other week.

2) What is the state of the code-base (i.e. how many parts of the code devs would prefer not to work with, how many bugs are discovered only in production, what is the CC, what is the size of the longest method/class, how many conditionals and static members are in the code, how much time it take for a new team member to do it's first check-in)

Code-base is quite good. There are some parts that are complex (like custom reports), but in general nothing is so bad that anybody hates to touch it. I can't provide any metrics on method/class/static members so far, will try to gather them soon. Usually it takes 1-2 days for newcomer to dig into codebase and start bug fixing.

3) What about collective code ownership ?

There are no owners. Sure, some people are more fluent on some areas, but everybody can change everything.

4) How many time you discovered/learned things only after releasing a feature and how are you dealing with that now

There were 2 major fails last year. One caused by missed requirements in Subversion integration plugin and another one due to critical bug found on production. That is quite rare cases. Sometimes bugs indeed come from production, but most of them are minor. Our testing process is good enough now to catch almost all critical bugs.

5) How much unknowns, uncertainties, unexpected-unpredictable events and changes there are in your domain and business and how you deal with them

Well, agile domain is quite fluid. But there is no immediate changes. In general we should react every year on latest trends in agile domain.

6) What about devops and support and operation of the system in production?

We have a dedicated support team (4 people) and 1 developer almost fully dedicated to support issues. Other developers help customers as well when required. We provide live chat support, email support and live skype sessions support when required. Support team is really responsive and to be honest that is one thing I proud of.

7) what about the features released, how much they are the right features for the users and for the stakeholders ? how much early the team spot the wrong feature?

We don't have stakeholders, only end users. Product vision comes from various sources, mainly from customers requests. However, we do not implement requests blindly, but try to find root solution. Last year we released only useful features, all of them are used by customers. Previously there were quite many mistakes and software started to bloat. We cut some features off and now are very careful with new functionality.

Let see if I understood correctly.

10) Now teams are releasing in production every other week and with single branching and the continuous delivery teams are going in the direction of daily releases (as soon as a single feature is ready is released). Do I understood correctly ?

11) Your domain and requirements are pretty stable so are technology and teams and people involved (i.e. few unexpected/unpredictable events and changes, few unknowns and uncertainties) and teams are able to deal with the challenges well with anticipation and reflections and with less/minor needs for reaction/adaptation/explorations. Do I understood correctly ?

3 additional questions

12) Are release and eventually rollback operations automated just like a one-click operations and so are the deploy to the automatic test servers?

13) A dev can look in isolation at 1 or few classes and understand their behavior and can safely make changes and test them, without the need to follow a dependency chain of more classes and check internal implementation details (that cannot be understood by looking at public members, interfaces, types, parameters and their naming) ? Can teams make architectural changes (i.e. change the persistence technology, change the presentation technology, change the authentication method/technology, change the caching or session state implementation) comfortably and gradually and without pain or huge risks ?

14) When you removed the time-boxing and at the same time adopted some kanban practices (from the report I understood WIP, leading time, just-in-time meetings as retrospective and planning) have you considered the possibility to keep both (as I understood time-box and kanban practices are compatible and so kanban and meeting with a fixed cadence are compatible, so as I understand all are valid options that team can adopt) ? What teams sensed in order to make the decisions and what consequences have observed ?

> 10-11)

Yes. However, daily releases are possible for SaaS solution only.

> 12) Are release and eventually rollback operations automated just like a one-click operations and so are the deploy to the automatic test servers?

Yes, deployment is automatic. Roll-back is semi-automatic so far, but we are working on fully automatic roll-back and it will be ready soon (for SaaS). However, customers can install TargetProcess on their own servers, and in this case there is no automatic roll-back.

> 13) Can teams make architectural changes (i.e. change the persistence technology, change the presentation technology, change the authentication method/technology, change the caching or session state implementation) comfortably and gradually and without pain or huge risks ?

UI layer - yes. Caches and persistence layer, not so easily. Codebase is 8 years old in some places and definitely there are parts that are hard to modify. Several years ago speed was more important than code quality, so we have dome debts to pay. New code is very clean and cool, old parts of the system refactored gradually.

> 14) When you removed the time-boxing and at the same time adopted some kanban practices (from the report I understood WIP, leading time, just-in-time meetings as retrospective and planning) have you considered the possibility to keep both (as I understood time-box and kanban practices are compatible and so kanban and meeting with a fixed cadence are compatible, so as I understand all are valid options that team can adopt) ? What teams sensed in order to make the decisions and what consequences have observed ?

The main reason to try Kanban was an ability to release each feature or bug fix separately, so we did not considered cadence of any kind. I don't think cadence is required in Kanban. But definitely team can keep it and see how it goes. Changes were not easy initially, but in 2-3 months situation improved and it was clear that Kanban works better for us.

Nice to hear of teams that found sustainable approaches to sw development and still pushing to improve. Thank you very much! A really interesting report.

Reply on news.ycombinator.com