The story telling/relevant example is pretty important in my opinion. It also tends to help uncovering situations, where one accidentally applies “wrong best practices”, that don’t apply in a specific project or situation.
We have official coding rules but many developers don’t understand the reason for the rule. Annotating them with stories would help in my opinion and also help to decide when to break such best practices.
“ Software architects must code, talk business, and tell stories. “
Another reference to a story of a story. There is a term ‘Architecture Astronauts’ coined by Joel Spolsky [1]:
The hallmark of an architecture astronaut is that they don’t solve an actual problem… they solve something that appears to be the template of a lot of problems. Or at least, they try. Since 1988 many prominent architecture astronauts have been convinced that the biggest problem to solve is synchronization.
Overall though, I like learning about success stories in highly challenging software deliveries.
So I appreciated the articles emphasis on stimulating brain by telling stories through relevant examples.
Hm, Microsoft bought Groove in 2005. In the same year they also bought FolderShare. Live Mesh was released in 2008 and Joel also wrote this article that year dissing them all. However, in 2007 Dropbox was founded doing the same and is now a US$10 billion company. Seems like they were going for the right target but were out-executed by a startup. At least, at first. Seeing how popular Sharepoint is at big companies, I wouldn’t say Microsoft is losing the war around file synchronization long-term.
It might seem like a nit-pick, but I wouldn’t use the term “popular” here. Blackberry was “commonly chosen”, iPhone proved to be “popular”. Commonly chosen but not terribly popular technologies have a hard time avoiding disruption.
Yes, SharePoint is the embodiment of “Enterprise” but MS is moving fast (and breaking things sometimes). They are quite fast at picking up “new cool stuff” and implementing it. I think having transitioned to a cloud environment helps a lot here.
TL;DR MSFT may still be evil but they’re smart and competent.
TL;DR MSFT may still be evil but they’re smart and competent.
They always were - at least, certain areas within the company. .NET, C#, Excel, PowerShell, Office Lens, Minecraft … there are a bunch of Microsoft products that are excellent, and in some cases have deservedly been market leaders for decades.
I’ve never had Sharepoint in that bag, though. Perhaps I should re-evaluate, it’s been a good many years since I’ve used it (and would have described that experience as “had it inflicted upon me”).
My main gripe with MS’s approach to things has been that they have always seen their customers as pawns at a corporate level. From nerfing Windows 3.11 on DR-DOS to restricting Minecraft EE licensing, it’s been clear that regardless of how well individual teams build products for their customers, the overarching philosophy is that their customers can and should be pushed under the bus for strategic reasons.
The story telling/relevant example is pretty important in my opinion. It also tends to help uncovering situations, where one accidentally applies “wrong best practices”, that don’t apply in a specific project or situation.
We have official coding rules but many developers don’t understand the reason for the rule. Annotating them with stories would help in my opinion and also help to decide when to break such best practices.
More importantly, it would highlight how many of them are “because I saw a blog post at ${hipCompany} that said so”
Any practice without user discretion is doomed to become institutionalized bloat.
All points are relevant:
Another reference to a story of a story. There is a term ‘Architecture Astronauts’ coined by Joel Spolsky [1]:
Overall though, I like learning about success stories in highly challenging software deliveries. So I appreciated the articles emphasis on stimulating brain by telling stories through relevant examples.
[1] https://www.joelonsoftware.com/2008/05/01/architecture-astronauts-take-over/
Hm, Microsoft bought Groove in 2005. In the same year they also bought FolderShare. Live Mesh was released in 2008 and Joel also wrote this article that year dissing them all. However, in 2007 Dropbox was founded doing the same and is now a US$10 billion company. Seems like they were going for the right target but were out-executed by a startup. At least, at first. Seeing how popular Sharepoint is at big companies, I wouldn’t say Microsoft is losing the war around file synchronization long-term.
It might seem like a nit-pick, but I wouldn’t use the term “popular” here. Blackberry was “commonly chosen”, iPhone proved to be “popular”. Commonly chosen but not terribly popular technologies have a hard time avoiding disruption.
Yes, SharePoint is the embodiment of “Enterprise” but MS is moving fast (and breaking things sometimes). They are quite fast at picking up “new cool stuff” and implementing it. I think having transitioned to a cloud environment helps a lot here.
TL;DR MSFT may still be evil but they’re smart and competent.
They always were - at least, certain areas within the company. .NET, C#, Excel, PowerShell, Office Lens, Minecraft … there are a bunch of Microsoft products that are excellent, and in some cases have deservedly been market leaders for decades.
I’ve never had Sharepoint in that bag, though. Perhaps I should re-evaluate, it’s been a good many years since I’ve used it (and would have described that experience as “had it inflicted upon me”).
My main gripe with MS’s approach to things has been that they have always seen their customers as pawns at a corporate level. From nerfing Windows 3.11 on DR-DOS to restricting Minecraft EE licensing, it’s been clear that regardless of how well individual teams build products for their customers, the overarching philosophy is that their customers can and should be pushed under the bus for strategic reasons.
This post is valuable to me. I specifically suffer from people not picking up the architecture knowledge I set on the table for them.