95212607
submission
mikeatTB writes:
Many Slashdotters weighed in on Steven A. Lowe's post, "Is Project Management Killing Good Products, Teams and Software?", where he slammed project management (PM) and called for product-centrism. Many commenters pushed back but one PM, Yvette Schmitter, has fired back with a scathing response post, noting: "As a project manager, I'm saddened to see that project management and project managers are getting a bad rap from both ends of the spectrum. Business tends not to see the value in them, and developers tend to believe their own 'creativity' is being stymied by them. Let's set the record straight: Project management is a prized methodology for delivering on leadership's expectations. The success of the methodology depends on the quality of the specific project manager..." She continues, "If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives—allwithin the prescribed budget and timeline.Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad." Where do you stand on project management?
94066541
submission
mikeatTB writes:
For software development, no significant developer activity is predictable or repetitive; if it were, the developers would have automated it already. In addition, learning is essentially a nonlinear process; it involves trying things that don’t work in order to discover what does work, writes Steven A. Lowe. You might see linear progress for a while, but you don’t know what you don’t know, so there will be apparent setbacks. It is from these setbacks that one learns the truth about the system—what is really needed to make it work, to make it usable, and to make a difference for the users and the business. In other words, the dirty little secret of software development is that projects don’t really exist. And they’re killing our products, teams, and software. Here's how.
91803803
submission
mikeatTB writes:
While agile and DevOps are belatedly taking on the problems of creating secure software, the original Agile Manifesto did not acknowledge the threat of vulnerabilities as a problem, but focused on "working software [as] the primary measure of progress." Without a security mandate, the incentives to create secure software do not exist, said Joshua Corman, founder of the Rugged Manifesto. Instead, almost every software program comes with a disclaimer to dodge liability for issues caused by the software. The oft-unread end-user license agreement (EULA) essentially states that people do not have to use the software, but if they do, the developer is not responsible for any damages. EULAs have been the primary way that software makers have escaped liability for vulnerabilities for the past three decades. That's changing as software takes an increasingly starring role in an expanding range of products whose failure could result in bodily harm and even death. Is your engineering team ready to deal with being held liable legally for security vulnerabilities and flaws.
89236701
submission
mikeatTB writes:
While Yahoo and Reddit are sold on banning remote work, there is generally increased acceptance of remote versus co-located teams, and the availability of effective tools that enable it are among the most significant trends affecting technology industry employment today. As with most things in business, productivity and cost are the dominant factors when choosing between remote and co-located workplaces. But there's no one answer. Which is the better fit for your software teams? Dave Fecak does a review of the science, and how peers in the industry are dealing with the modern workplace. One interesting take on the issues is raised by ThoughtWorks' Martin Fowler: Individuals are more productive in a co-located environment, but remote teams are often more productive than co-located teams. This is because a remote team has the advantage of hiring without geographic boundaries, and that enables employers to assemble world-class groups.
88977635
submission
mikeatTB writes:
Some things in the programming world are so easy to misuse that most people prefer to never use them at all. These are the programming equivalent of a flamethrower: You might rarely be in the position to really need one, but every once in a while it turns out that you need to take down a forest. In that case, there’s no easier way than going Rambo on your codebase. That's where a few of the old, forgotten code constructs come into play. Creative use of features such as goto, multiple inheritance, eval, and recursion may be just the right solution for experienced developers when used in the right situation. Is it time to resurrect these four forgotten code constructs?
