Reading the forums it is clear that the latest update had the same quality as other major updates had. ZoS keeps showing their failure of fixing bugs long know, fixing bugs reported by PTS testers and managing to not add new bugs with every single update.
Iam not here to bash on the developers. I believe they are working in a world of pain, working over hours until complete burnout without getting much support or gratification from their leadership.
So what is going on there? Iam software developer and software architect myself working on technical migration from old legacy systems (c/c++, visual basic and so on) to new ones (e.g. C# / Java, distributed systems...). I happen to encounter the same issues in my everyday work life. However in my world things are changing, or already have changed. The problem is the culture and mindset of a company (or mostly the upper and middle-management). They still believe that writing code / building software systems is like building a house or manufacturing a car, e.g. the same old every day which gets pipelined and can be measured by metrics like amount of manufactured cars versus time. E.g. throw more workers on a production line to speed up production or scale with more production lines / plants. In the mind of these people it works like this: if a woman needs 9 months to give birth to a child, 9 women should be able to do it in 1 months.
Software is different. Building a car is well understood, it is an easy task and can be easily separated in even easier sub-tasks (yet companies like GM manage to extremely suck at it while LEAN companies like Toyota produce more, at higher quality and with happier employees). See
http://noop.nl/wp-content/uploads/Simple-vs--Complicated-vs--Complex-vs--Chaotic-2-pi.jpeg
Basically software-projects are mostly on the right and upper side on the chart. And stuff like that is well known for over 20 years.
You remember Microsoft from 10 years ago? Huge anti-agile company releasing a product maybe once every 2-3 years (Windows, Office, Visual Studio and so on). They were on the brink of self-destruction losing to Google and Amazon esp. in the cloud business. A new CEO took over after Steve Balmer and started a complete turnaround, a change of culture. Now, they are extremely successful, open for open source software and employing all kinds of agile practices (test-driven design, continues integration, continues delivery, devops...).
You know, using their cloud development services (team service + visual studio online) or any Azure-Cloud product they will know when you have an issue way before you know it and act accordingly. More so, if they release an update you
wont notice! Maybe a function usually takes 10 milliseconds, it might take it 1 or 2 seconds suddenly for once call, and then you got an update without any downtime. Its modern development at its best. Release fast and often, fail fast (automatic unit testing before production) and succeed fast (release updates at least once every 3 weeks, = 1 sprint there).
Think of Netflix is another prime example. Imagine the press if Netflix ever had an outtage for 12 hours. Oh my god...
But back to ESO and ZoS. Most game companies somehow managed to lose the touch to the industry. You'd think that game development should be much more extreme, agile, experimental than industry business... well, probably not since EA, Activsion, Ubisoft and co bought every indi-dev studio out there...
anyway, for ZoS: PLEASE STOP DOING WHAT YOU ARE DOING AND HOW YOU ARE DOING IT.
-> stop pushing features/must-dos on your development teams!
-> stop setting hard timelines! (like 1 DLC every 3 months, 1 expansion per year). SORRY THAT IS ***
-> remove the direct influence of the middle and upper management from the development teams
-> management is supposed to give guidance and a strong vision. Example from MS again: what do we want to accomplish and focus on in the next 18 months (= 1 scenario or epic)
--> the teams product managers/owners then plan in more detail what should be done in a scope of about 6 months (= 1 season or goal)
--> management updates their scenario every 6 months, so every season, to make sure that this scenario is still on target (= is what customer wants the most and is still valid in terms of market, strategy and so on)
--> teams plan in 2 to 4 weeks sprints, e.g. features are what can be done in that timeframe, tasks are parts of this that can be done in 1-2 days.
--> the team pulls the work, it is not pushed onto the team. This means the team only accepts as much work as they can manage to deliver in quality in that timeframe
--> the team does not work on features if there are too many bugs in the system (Microsoft has 5 bugs per developer as red line)
--> developing and finishing a task also includes writing (lots) of automated unit tests (Microsoft has NO testers anymore, their VSO team alone moved from manual testing and automated ui testing with >30000 ui tests that never all worked and took days to run to > 70000 unit tests that are run every checkin in <7 minutes). If your architecture is not testable: make it testable, this is a design goal every project should follow
--> release often: do not drop the work of 3 months onto any system, be it live or PTS. the work of 3 weeks can be better tested, also remember: automatic tests > manual tests. Humans should not do the work a machine can do as well or better!
--> use feature toggles: e.g. deploy new features but only enable them for a few users first. Then if all goes well enable it for all. If things go wrong, disable it, fix it, reenable it
--> do not take your service down for anything. A resilient modern system works even if parts are down by reducing functionality, not by dissallowing it
--> listen to your developers and architects (hope you have some): let them do their work and do not tell them how to do their work. Tell em what to do next, what is the most important and then let em decide how to do it.
--> and once more: do not push timelines / deadlines on the team. It takes as long as it takes...
Wre rather wait a month longer than test your *** code.
)
