今日推荐开源项目：《404-PageNotFound》
今日推荐英文原文：《On Sustainable Software Development》
今日推荐开源项目：《404-PageNotFound》传送门：项目链接
推荐理由：404 错误应该算是每个网站都不可避免的了，而如何设计自家网站的 404 页面也算得上是门学问。这个项目收集了各个网站上的 404 页面，便于以这些页面为原材料寻找灵感，看到设计的好的还可以顺手点个赞。
今日推荐英文原文：《On Sustainable Software Development》作者：Dan Goslen
原文链接：https://medium.com/dev-genius/on-sustainable-software-development-69acd0749559
推荐理由：一直通过超负荷来完成任务不能算是健康的开发过程
On Sustainable Software Development
“Hero” programming only lasts so long.
It’s 9:45 pm on New Year’s Eve. I was supposed to be downtown a few hours ago with a group of friends to and stay up to be part of the Raliegh NYE celebration (which, btw, features an acorn drop).Instead, I was on my computer. Hunched over, manually verifying the last of our billing statements were ready to go out. The past day had been an exhausted one. Every process had gone wrong, no one was around due to the holiday, but we had to get statements out.
We thankfully did, and everything was fine.
Except it wasn’t fine.
It wasn’t fine that I was still in the office.
It wasn’t fine that I had broken promises to my friends because of work.
It wasn’t fine that we were keeping this system afloat by sheer willpower.
Software Development Shouldn’t Be Heroics
How many of you have worked on a team that always had to be putting in “heroic work” or were always “stepping up to the plate” in 11th-hour situations? Were it was normal for team members to work late, over the weekend, or skip lunch — or all three.These teams usually get praised if they hit the deadline, and their achievement is hailed as “grit” or “great work.” If they miss the deadline, though — they are scolded for not making the deadline and wind up working just as long to get in done when they can.
While these situations are nearly inevitable — every team will hit some form of crunch time that requires some extra work — it should be the norm. And it shouldn’t be seen as heroic work.
When teams are constantly in this state of frantic overwork, something is just plain wrong. They aren’t building the right software. They aren’t investing in the right places. They aren’t having the correct retrospectives with themselves or with product owners. Something needs to change.
Development Should be Sustainable
One of the core principles behind the Agile Manifesto isAgile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Its often an overlooked one too. Why?
I believe it’s because teams that embrace all the other principles — continuous delivery, short iterations, prioritizing developer efficiency, etc. — leads naturally to a sustainable pace. It also means that if a development team is doing those things well, there can be useful estimates from the team about when they can complete work. This makes product owners happy as their job of predicting features to users, and setting direction for the product is now more straightforward.
I also think there is a slight tendency for developers to want to be perpetually busy. There is a false sense of meaning that comes from always being busy, isn’t there? Our whole society says that if we are busy or hustling or continually working that we are doing something meaningful.
I’m not condemning hard work at all! I am simply saying there are more meaningful things than working long hours to fix a bug on New Year’s Eve.
How to Get There
How does one take a team that regularly feels up against the wall or behind and create a sustainable cadence?I’ll be blunt: it won’t be simple or easy. Chances are you will find that there is pushback from not only the product owners or managers but even pushback from the team. Teams who have lived in this “hero” world might start to think they won’t get noticed or that they won’t be needed. Change is hard.
In my experience, getting onto a path towards sustainable pace requires a few things:
- Admit the team is overworked. This is harder than you might think. Some developers don’t want people they work long hours because they are afraid it means they will look inadequate (i.e., “You had to work the weekend to finish that simple task?”). The team and managers need to agree.
- Start holding a retrospective. It doesn’t need to be an hour-long, and it doesn’t need to be every two weeks. Heck, you don’t even need a big meeting to start. Create a shared document and pass it around, asking team members to add things they would think the team should keep doing, stop doing, and start doing. After a day or two, share the feedback during your typical standup or set up a 15-minute summary.
- Identify from your retrospectives one thing — yes, one thing — to try. It could be starting something, stopping something, investing in a system, etc. Just pick something you think will help your team.
- Keep doing that over and over!
It’s just also hard to follow. It takes real work and a commitment to change for a retrospective process to make an impact. Everyone needs to commit to the process, and everyone needs to be honest about their opinion.
Before wrapping up, consider your team’s “one thing” for a retrospective to define what constitutes an emergency and what does not. Define if there are cases in which someone needs to work late or over the weekend to complete or when it can wait till the next workday. This definition is important because it will help your team get out of the feeling of perpetually being against the wall.
Development shouldn’t be a constant state of exhaustion and hero programming. We need to work together as teams to create sustainable workflows that allow our teams to build software effectively for the long-haul. I hope this guide helps you and your team!
Happy coding!
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
