Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@1989 I still disagree with the need for scheduled releases. The last place I worked at also had this orthodox commitment to release schedules. There were a few reasons for doing so:
1) Agile and scrum were industry buzz words
2) We weren't in a place to entertain the idea of releasing after each bug/enhancement (its hard to get there). Our suite of tests was small and we had no integration tests. We relied on a QA team to find our bugs. The app was monolithic. All devs worked out of the same "version's branch."
IMO, that last one is particularly bad. All devs worked out of the same branch! Today in my company, each enhancement and bug gets its own branch and this concept of "versions" is gone. You can pause your feature branch and switch, fix the bug, merge the bug fix back into both prod and your feature and keep going.
We also use micro-services for everything, it's easy to update one piece knowing it breaks nothing.
My last company scoffed at the idea, I'm proving them wrong. -
@1989 absolutely, I meant to add that but I ran out of room. With a cloud-based application it is far easier for example, clearly. Installations at a client location pose a much different set of challenges.
In my experience the release schedule is a recurring, arbitrary date and you have to try to guess the future as far as how long it will take you to do X amount of things scheduled for the release (not counting incidents that arise). I never liked that.
IMO, releases should be determined by what work has been completed in the "pool of completed work" and not planning what will be included before its done. I also find that vaporware declines and a shift towards selling the software based on what it has instead of what is planned is achieved.
I forgot to mention our partner company I was ranting about has a cloud-based application. They STILL stick to this scheduled-release-date ideology. Over here we don't and it's great. -
So adding onto my statement of "releases should be determined by what work has been completed in the "pool of completed work":
If your software is a phone app or an installation at client offices, that kind of thing, if there is a bug and you need to fix it and there are already 3 features that are also complete, branch prod for the bug fix then merge back in and immediately release it. They get a bug fix with 3 new features. They didn't even have to wait for an arbitrary date to get their bug fix.
That's the methodology that we follow here and all I can say is that it works really well. It's a much better experience than at previous places of employment and client loyalty and overall morale is great.
when your code is a mess but everything work out in the end
When you keep getting +1s on a rant you posted a month ago.
Go big or go home.
I HATE the idea of only releasing on pre-determined schedules despite work being completed and just waiting for that day to arrive.
I'm a co-founder of a small software company. We have partnered with another particular company that also writes software. Some of our clients have access to paid content of that company's services through our application.
Every once in a while, our clients will report issues with that company's service to us, because they access it through our application. They think it's our issue.
We then pass the report on to the partner company, telling them that their stuff is broken. Their reply goes like this:
"Ok. We'll get the bug fix scheduled, and we'll release it next Thursday."
"Next Thursday? The issue is now, they can't use the service."
"That's our scheduled release date."
O.M.G.
We voluntarily walked away from our safe, cushy jobs working for other people, taking enormous pay cuts to start this company. Now, we're 6+ years in, disrupting established fat-and-happy competitors in this space. I GUARANTEE you that if we had that same attitude, we would have been absolutely obliterated early on.
We are quick. Guided by kanban boards, our suite of unit tests and integration tests is vast and kick-ass. With continuous integration and the click of a button we know if we broke something or if the piece we're working on is ready to be pushed to production, IMMEDIATELY. Our "release schedule" is when the damn thing is complete.
It isn't all bad. Our integration with them has been beneficial for both of us. I just loathe their snail's pace which negatively affects our mutual customers. It can make us look bad, and we can do nothing about it.
Blah.
rant
business