41–50 of 201 posts
IMO it's all about working with smart, motivated people who can work independently without the raging ego to cross borders to expand their computational Lebensraum. I've run remote projects with old friends over 3-5 years and it's gone spectacularly well. In contrast, I've been on SCRUMed and Agiled projects where the resulting overhead on those who can already get work done without SCRUM Master Jar Jar's constant in…
Restricting a creative process into some pre-baked confines of thinking doesn't make a sense to me. Some rules are vital thought those should not get too much in the way.
I think only organically growing your rules makes sense and you've got to accept there will be situations where you have to break them or they won't allow you to adjust your strategy. Imagine a huge company that standardized on some well-tested processes/methodologies that served well in the past and were adjusted as it was growing. Staying with the same set of methodologies might kill the company's future if the structure of its workforce changes, technology moves forward, competitor has more efficient methodology for achieving returns etc. Often methodologies are used internally for political gains, pursuing promotions and power and "change agents" don't really care that much about improving efficiency, instead riding the wave of a currently cool methodology as recognized by the upper management.
> rigorous studies of software development methodologies haven’t been done A simple search proves this is false. Paired with author's other unsupported and stupendous claims I have to doubt the validity and worth of anything else author says.
As with any process of production the move to change it in to a documented repeatable process complete with middle management has taken place.
Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from.
Fraser: One of the problems that is central to the software production process is to identify the nature of progress and to find some way of measuring it. Only one thing seems to be clear just now. It is that program construction is not always a simple progression in which each act of assembly represents a distinct forward step and that the final product can be described simply as the sum of many sub-assemblies.
(Full transcript of the 1968 conference here. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PD... It's a really fun read!)
Furthermore, if you have a very capable team, you may not even need a formal "Methodology".
Maybe they all don't "work" because people suck and get lazy? Things can be very pleasing when one works with developers use the planning tools and have a leader who never relents at keeping the team on track with a given methodology, all without being a bully of course. Of course it's rare in the real world, but it does happen.
I left my last job because my time had degenerated from doing cool stuff to fixing the stupid errors that my colleagues were making because they were lazy. Allowing some coders to be lazy in terms of adherence to coding standards and methodology has to be one of the best ways to get rid of your good programmers. For example, we had coding standards requiring a comment explaining the contract for each method written,…
class Shape
{
public:
void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS);
void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS);
void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS);
void SetXRelativePosition(int x, LengthUnit units = LengthUnit::PIXELS);
void SetYRelativePosition(int y, LengthUnit units = LengthUnit::PIXELS);
void SetSize(uint height, uint width, LengthUnit units = LengthUnit::PIXELS);
void SetHeight(uint height, LengthUnit units = LengthUnit::PIXELS);
void SetWidth(uint width, LengthUnit units = LengthUnit::PIXELS);
void SetColor(Color color);
};
class Shape
{
public:
/**
* SetAbsolutePosition sets the Shape absolute position
*
* @param x The absolute X coordinate
* @param y The absolute Y coordinate
* @param units The units of the coordinates
* @returns Void
*/
void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetRelativePosition sets the Shape relative position
*
* @param x The relative X coordinate
* @param y The relative Y coordinate
* @param units The units of the coordinates
* @returns Void
*/
void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetAbsoluteXPosition sets the Shape absolute X position
*
* @param x The X coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS);
/**
* SetAbsoluteYPosition sets the Shape absolute Y position
*
* @param y The Y coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetXRelativePosition sets the Shape relative X position
*
* @param x The relative X coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetXRelativePosition(int x, LengthUnit units = LengthUnit::PIXELS);
/**
* SetYRelativePosition sets the Shape relative Y position
*
* @param x The relative Y coordinate
* @param units The units of the coordinate
* @returns Void
*/
void SetYRelativePosition(int y, LengthUnit units = LengthUnit::PIXELS);
/**
* SetSize sets the width and height of the Shape
*
* @param height The length of the height
* @param width The length of the width
* @param units The units of the lengths
* @returns Void
*/
void SetSize(uint height, uint width, LengthUnit units = LengthUnit::PIXELS);
/**
* SetHeight sets the height of the Shape
*
* @param height The length of the height
* @param units The units of the length
* @returns Void
*/
void SetHeight(uint height, LengthUnit units = LengthUnit::PIXELS);
/**
* SetWidth sets the width of the Shape
*
* @param width The length of the width
* @param units The units of the length
* @returns Void
*/
void SetWidth(uint width, LengthUnit units = LengthUnit::PIXELS);
/**
* SetColor sets the color of the Shape
*
* @param color The color to be set
* @returns Void
*/
void SetColor(Color color);
};
The better alternative is to comment only those things where the comment provides useful information, so that when you see a comment it strikes you as something you should pay attention to rather than some boilerplate to be ignored because 85% of them are mandatory but useless.
-1 for being too short of an article; I wanted to hear better specific examples, and was sad when I saw the comment section starting :-)
Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven. Our emotion comes into play when it comes to drive, motivation, hard work, creativity, and organization. Creating software requires motivation, creativity, organization, etc. Our emotion is behind software and we simply try to manage it with software developme…
But there is nothing stopping you from incorporating emotion into your logical models.
They work, but you still need very capable people (developers, managers, product owners, etc). Furthermore, if you have a very capable team, you may not even need a formal "Methodology".
(This actually perfectly matches my experience. A good team can work in spite of a methodology; a bad team won't work regardless of the methodology.)