Well, it's been a few months since I posted the tag-wiki for .

I haven't gotten any feedback on that tag-wiki. How useful has it been to others? How many people have even read it? How did it affect my reputation?

One thing I have observed is that it hasn't been revised by anybody. That could mean that it's pretty good, but it could also mean that it is not seen as worth improving. It could also mean that the only people looking at it are people who don't trust themselves to revise it, or have not been granted that capability.

If it was wasted effort, that's one thing. But if it prevented the evolution of a better tag-wiki, that's an entirely different thing.

One aspect of this is that very few people who are designing their first database think of this as the beginnig of a whole new phase of their career. Most of them think of the database they are designing as one small aspect of a project they are taking on. For someone in that mental set, the tag-wiki I wrote may seem kinda long and tedious.

For someone giong into database-design big time, he or she needs to know everything in the tag-wiki, and probably in greater depth than what I wrote.

So what's the mechanism for tag-wiki authors to get rewarded or not rewarded based on the quality of their input?

Added in response to a response:

I've thought about trying to make the database-design tag-wiki shorter and better, but I don't know how to do it. There are plenty of people besides me who could edit it. Maybe some of them are better wordsmiths than I am. Or have a better understanding of database design than I do. Or are more in tune with current methodologies than I am. Or have a better handle on what to leave in and what to leave out when constructing a tag-wiki.

Then again, maybe database-design needs a longer explanation than Java does, for example.


I have also wondered about the value and reception of the wikis I've written and edited.

There is one category of feedback right now: further edit by other users. If some rewrites large parts of you work you know they thought it was lacking. If they fix spelling or grammatical errors without diddling the context you an guess they found it to be reasonable.


I just took a look at that tag wiki. Yeah, that's too long.

I'll also say that you're making assumptions about software development process. In a more agile development approach, database design is the activity that starts right after I find that I need to redesign some aspect of the database in order to make my failing unit test pass, and which ends soon after my failing unit test passes.

  • What you are describing sounds to me more like database redesign than database design. How does the database first get designed in an agile process? I have to admit that the only cases I've seen where the developers described themselves as "agile" looked like "quick and dirty" to me. – Walter Mitty Feb 26 '11 at 4:04
  • @Walter: the database first gets designed the same way - first time I need it in order to make a failing unit test pass. This is more than just "agile", it's more like "stubborn test-driven development", and I'd stop doing it if it didn't work. – John Saunders Feb 26 '11 at 4:20
  • I guess I just don't understand that methodology. I had thought that methodologies that are heavy on initial analysis and design pay off later on by getting to a satisfactory result with fewer iterations. Of course, the value of intial analysis and design does not scale linearly with project size. Neither does the cost of initial analysis and design. – Walter Mitty Feb 26 '11 at 13:54
  • @Walter: in my experience, the more initial design you do, the more time you waste when you find your requirements changing, or when you find that they were inaccurate to begin with. It's not about the design; it's about the result. In any case, this particular discussion is better suited for programmers.se. – John Saunders Feb 26 '11 at 15:44

Not the answer you're looking for? Browse other questions tagged .