55 réponses à ce sujet

[Fast Jimmy]

This guy is not a very good developer.

 

You have a skewed perception of the job of the engineer. Why doesn't the engineer understand the business side? They deal with it every day. They are constantly in different stages of the cycle. I do not understand this reasoning.

 

Because you don't understand what I mean when I say the Business side. You are focusing on being a good programmer and foreseeing programming concerns and problems... not BUSINESS concerns and problems. Developing software does not make you an expert on the business your software is supporting.

 

A software engineer for a car company, making computers for automobiles doesn't understand (or likely even know about) Transportation Cabinet requirements that now add further complexity to their task. They don't keep up to speed with new legal requirements or developments within Congress, and so wind up with last-minute complications because they didn't take this into account when the original project was scoped.

 

A software engineer for training software doesn't realize that halfway through migrating their entire suite of training programs to a new platform, a new set of teaching requirements is added for an obscure certification program. Because they are focused on completing the migration and not on the individual components of some of their smaller services, the training program is worthless upon moving to the new platform, resulting in complaints about quality and demands for refunds.

 

A software engineer perfectly plans staffing and resource allocation for a large project that will require the assistance from a support unit in Marketing once the project nears completion. Because this is a special project and a department not usually associated with the development team, meetings are held at the beginning of the project to level-set expectations. Sixteen months later, when the Marketing team is needed, there has been a reorganization and most of the unit's work has been outsourced. Due to no one properly informing the unrelated development team about HR decisions that didn't directly affect their business, the project is delayed because the work cannot be completed by an outside vendor due to security restrictions.

 

 

 

These aren't bad software engineers - they are people who are experts at the programming and development aspects of their job who can't possibly be expected to manage their complex work while also monitoring dozens, if not hundreds, of other potential downstream impacts that have NOTHING to do with software or development cycles, at least not directly. Unless you expect a Software Engineer to be on top of every government regulation for every possible project in the works, every organization and staffing change that occurs across the company, every product update that could occur between each line of business or any vendor support lines of business, all while ALSO doing their job of developing software/managing a team of people who develop software... I'm sorry, that's just not realistic. 

 

Whether your company is manufacturing, SaaS, AaaS or any number of other service models, it still just does not work to have your developers try to be the Masters of the Universe. It sets terrible long-term expectations and opens the door wide open for all types of communication and managerial failures. Instead, having one person for each project coordinate the experts across the board on a myriad of subjects to make sure everyone is working on a cohesive, solid goal is much more logical. A (good) project manager doesn't just collect requirements, regurgitate them to development in the appropriate Project Management form template and then watch a checklist tick itself off... they communicate, plan and constantly reaffirm that there is no potential for misunderstandings or problems. That's the entire point - to save any one department from trying to carry the entire load of responsibility, since it will inevitably result in them carrying the entire load of guilt when something breaks due to one (obvious in retrospect) mistake.

[BigEvil]

Gamers are strange indeed. The rights of the consumer are paramount in this industry, but they also have responsibilities too.

 

No developer or publisher will take their audience seriously when stuff like this continues to happen:

 

 

Clearly they should have listened to their fans and made the next Call of Duty into a fantasy football management game where your team consists of dragons, that you can romance.

[SmilesJA]

Edit. 

[Fast Jimmy]

I totally get what you are saying jimmy. My complaint is against companies hiring huge scrum masters or agile technicians when the developers are capable of doing it themselves. You obviously know that agile cuts both ways from a management and business side. When ward cunninghum and kent beck came together in that room and created the process of agile as a software engineering principle they know exactly whay they were doing. Software craftsmanship made by robert c martin, goes back to the original vision of what agile is supposed to be. The business decisions will be there, but when the management makes decisions for the developers based on whatever they think instead of the whole process, that hurts the the business as a whole Software is about long term and not a spur of the moment type of thing.

I don't disagree and I do appreciate the intent of the Craftsman approach. After all, it makes sense that the people who are the experts at creating the product should be the ones guiding the process, right?

Except that this isn't a fine oak chest made by a carpenter or a high quality blade made by a blacksmith... it's a complex set of instructions, logic and design framework. If anything, it's the religion of a computer - it tells them what the rules are, how to think and what things are valuable and what things aren't. While the programmers will be the ones to breathe life into that construct, there will be requests, needs and demands made for the system that go beyond the scope of what any programmer should legitimately be expected to have an understanding of.

A project/scrum/agile manager is intended to be a more efficient utilization of resources. Have those with the in-demand experience and skills tied to coding create the software, while those with project maw cement backgrounds keep an eye on the larger picture.

I don't like project managers in most instances, BTW. I find they are either 1) oblivious to the real takes at hand and try to squirm their way out of any responsibility with their defense always being the project task checklist being completely checked off and any problems that arise were "out of scope" or 2) they are demanding task masters who push a project out the door far before it is ready because they require it for their quarterly balance sheets. But when they work properly, it keeps everyone focused, on task, in the loop and winds up being a much more productive use of everyone's time than laying every project at the feet of IT/development and hoping someone there can take the reins and run the show.