Read on to see what I say about these and where the downfall lays.

One of the great things about the late 80s and 90s dot-com boom and bubble were that companies were starting up that abandoned the management hierarchy. This was fantastic! It meant that anyone's opinion was as worthwhile as anyone else's! Of course, this had potential pitfalls- anyone's opinion was as worthy as anyone else's, so there was plenty of room for debate as to what course of action would be taken with no decision making force in place.

Avoidance of Hierarchy

Imagine a company that's just starting out, with four employees and majority rules voting in place of hierarchy. There's simply no tie-breaker, and no management above to dictate a decision out of the debate or deadlock

There's room for having designated owners of projects and placing them in hierarchical positions as decision-makers, and having an open door policy for both opinions and other concerns to have a voice.

By making all members of an organization equals, everyone is done a disservice.

Avoidance of Design Documents

Design documents are useful things, but they require a little temperence of individuality to use. The programmer who sees himself as an artist may resist using design docs, saying a broad sweeping plan laid out in flowcharts is enough- that putting the features in a forum or database to discuss and change at will is enough to keep the team organized.

While programmers who organize their development in this way achieve amazing results, this is not a way to run a serious project that actually has to be supported. Help systems, GUI design, documentation, all rely on knowing what development folks are actually going to implement. All too often, the artist-programmer who keeps a development plan in a database or flowchart will ignore one feature and develop a new one not even on the list, and support and documentation only find out about it a week before release.

Design documents are the answer here. The System Level Design document, or SLD is the first step. It is approved by committee before any coding begins, and once approved as the final draft, it does not change unless voted upon. It outlines each feature, who's responsible for it, how many man-hours it will take to complete, and what the benefit is. The SLD is created so that every member of the project knows precisely what the project requirements and features will be.

After that, Component Level Docs (CLD) are created by the people responsible for the component features. The CLD contains the feature, how it will be implemented, and most importantly, what other teams it hits in terms of responsibility- what the GUI folks will have to do for this feature- what the documentation/helps people will have to write about new feature.

Once those docs are approved by everyone, they aren't allowed to change, so no features getting added, no features removed, without approval.

there's some validity to artists creating in the software world, but doing a site in flash breaks usability, each product a different logo breaks branding and marketing, and he shouldn't have an impact on those things especially if he can't get his mysql done.

Companies are not religions. Companies are entities that only deserve loyalty for as long as they are loyal to their employees.

And coders who see themselves as artists are great people, and good developers, but in a project with more than one person, you need design docs and approval so that the artists know what the canvas looks like.

This is not the first time I've encountered coder-as-artists folks who insist they're above/outside of needing design docs and any sort of order.

Common features that coder-as-artist types seem to exhibit are the ability to be an armchair marketing-type, gui designer, ceo, and support specialist. No doubt in small companies everyone has to take on many different tasks- but the coder-as-artist type is the one who will send email to the whole team talking about how the whole company is going down the drain because they haven't done X, where X is some wild-hair idea about branding each product with a different company logo- because no one else is. Alternatively, the coder-as-artist can also take on the attitude that the business is sunk, because no money is coming in and everything must be done just as everyone else does. In any case, they're fairly easy to spot because they attempt to have their hands in everything. This isn't always a bad thing, and there are people who are talented at a broad range of subjects; But when it gets in the way of other people doing their tasks by refusing to accept hierarchy or refusing to accept design docs that benefit others, the coder-as-artist quickly becomes an impediment.