I came across this nice article outlining some of the tips for implementing the software release process.
Software Development process is not complete and mature without a well-defined release process for the software applications. Every software application needs to be delivered or deployed at some point in time and for agile projects, this is happening more often. Therefore, there is a need to maintain software quality across the application releases to avoid deploying untested or malicious code to production environments.
Defining a release process for software applications helps in ensuring that software releases maintain a constant release quality. In addition, software changes and new features are traceable or can be correlated to specific releases easily. As a result, changelogs and release notes are easier for a generation.
I do agree with most of what is being suggested. And if there’s one thing to add to these suggestions, it’d be a clear versioning convention. Personally, I’m a big fan of the Semantic Versioning.
Today I came across yet another interesting application – Notion. It can be a simple note taking app just for yourself, or a collaboration tool for a whole team, with knowledge base, tasks, and project management. There’s also a way to have other types of structured data, like CRM leads, etc.
I wish I had the time to play around with it right now, but I don’t. So I’ll leave it here for the next time.
When it comes to project management, there are many certifications, guidelines, and suggestions all over the web. But it’s often difficult to pick the right one. Some are overly complicated. Others are too simplistic and don’t cover even the whole project lifespan.
P3.express, however, looks good. It covers the project management process from the early days, when it’s not even clear if the project will proceed at all, to the tasks that need to happen after the project has been fully completed. The whole flow consists of 37 activities in 7 sections, with each one of the activities being well documented and explained.
This one is definitely worth a try. Especially if you ever felt like this:
I really liked “OPP (Other People’s Problems)” article which talks about handling of responsibility for things that other people should be responsible for.
If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.
This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.
And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.
That kind of grinding frustration can wear you down over time. I know, because I’ve been there.
Not only the article describes the problem, but it provides a practical approach to dealing with it.
In the last few years, I was going through a very similar thinking process in my head, but I’m nowhere near the well-defined suggested approach. I wish I read this much earlier in my career. Much much earlier.
Here’s a quote for those of you who couldn’t make it through:
Why software tasks always take longer than you think
Assuming this dataset is representative of software development (questionable!), we can infer some more numbers. We have the parameters for the t-distribution, so we can compute the mean time it takes to complete a task, without knowing the σ for that task is.
While the median blowup factor imputed from this fit is 1x (as before), the 99% percentile blowup factor is 32x, but if you go to 99.99% percentile, it’s a whopping 55 million! One (hand wavy) interpretation is that some tasks end up being essentially impossible to do. In fact, these extreme edge cases have such an outsize impact on the mean, that the mean blowup factor of any task ends up being infinite. This is pretty bad news for people trying to hit deadlines!