August 17, 2015 at 12:14 pm
robert.sterbal 56890 (8/17/2015)
A wiki for people in technology to document issues might be a helpful tool in learning from our mistakes.Does anyone use one?
We do. It's also the most unread item in the company even though everyone knows about it.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 17, 2015 at 12:40 pm
I use a wiki extensively. We document all our processes in it. It makes a whole lot more sense than documenting them on my hard drive.
412-977-3526 call/text
August 18, 2015 at 7:38 am
Jeff Moden (8/17/2015)
robert.sterbal 56890 (8/17/2015)
A wiki for people in technology to document issues might be a helpful tool in learning from our mistakes.Does anyone use one?
We do. It's also the most unread item in the company even though everyone knows about it.
We also have a knowledge base repository, and when I assign my developers to write articles documenting their code and processes, the whining is incredible. They put my two year old to shame.
MWise
August 18, 2015 at 7:44 am
MWise (8/18/2015)
Jeff Moden (8/17/2015)
robert.sterbal 56890 (8/17/2015)
A wiki for people in technology to document issues might be a helpful tool in learning from our mistakes.Does anyone use one?
We do. It's also the most unread item in the company even though everyone knows about it.
We also have a knowledge base repository, and when I assign my developers to write articles documenting their code and processes, the whining is incredible. They put my two year old to shame.
MWise
It is amazing. It kinda reminds me of many of the questions we get on forums that are right there in Books Online or a very simple Google search but people seem to want the quick answer of an "expert" rather than spending any time learning how to use an incredibly useful tool.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 18, 2015 at 3:59 pm
Jeff Moden (8/18/2015)
MWise (8/18/2015)
Jeff Moden (8/17/2015)
robert.sterbal 56890 (8/17/2015)
A wiki for people in technology to document issues might be a helpful tool in learning from our mistakes.Does anyone use one?
We do. It's also the most unread item in the company even though everyone knows about it.
We also have a knowledge base repository, and when I assign my developers to write articles documenting their code and processes, the whining is incredible. They put my two year old to shame.
MWise
It is amazing. It kinda reminds me of many of the questions we get on forums that are right there in Books Online or a very simple Google search but people seem to want the quick answer of an "expert" rather than spending any time learning how to use an incredibly useful tool.
Thats odd - we have a confluence Wiki, and while not complete is definitely used by 1st level support and the developers have their own space which is regularly updated.
I think if the info is good and easy to find people use it, and then the developers especially don't get dumb questions and get to focus on what they are doing.
Maybe its a culture thing but our wiki is quite often the easier way to do something
August 20, 2015 at 4:02 am
For a development Wiki as a 'group memory' , I use DocuWiki on a Synology box. It is no effort to maintain and things don't get lost. I think a wiki is the right place for this. I go't like either Gitter or Slack as a place to put documentation because information is all in one stream, and it is difficult to structure. stuff gets lost and forgotten.
Best wishes,
Phil Factor
August 21, 2015 at 11:10 am
Great article Phil, and great comment Jeff. I've watched people bring in the shiny new things and have it blow up in their faces, and at times I've been the boring old prophet of doom that everyone ignores until after catastrophe strikes. I changed from being a lover of shiny new things to being a boring old prophet of doom very early in my career. Unfortunately too many people don't learn from their mistakes so they never make that change.
Something that's perhaps even worse than adopting the latest shiny new toy is attempting to build a shiny new toy with no idea how to do it and without employing enough people with experience in breaking new technological ground. This can be even worse when there is no fixed functional specification or requirements statement for the shiny new toy, which is all too common, and even more so when it is required that some components of the project will be built using the latest over-hyped fad and others the using previously "developed" shiny new toys that never made it beyone the drawing board.
Then of course we have plenty luddites in the database game, amonst DBAs as well as amongst developers; Jeff mentioned the "no busines logic in the database" crowd throwing away all constraints (and hence all normalisation), but they aren't our only luddites. There's also the "no serializability" crowd - not people who use read committed when that's all that is needed, we aren't luddites, but people who refuse to look at whether using repeatable read or snapshot or serialisable isolation will eliminate problems that are going to turn up with read committed simply because the business logic clearly implies stronger isolation than read committed. And those who ban dynamically constructed SQL even when it's clearly both perectly safe and the most effective solution to the business requirement, or insist that xp_cmdshell never be used, or insist that stored procedures and user defined functions are not to be permitted.
So we boring old prophets of doom have a lot more to cope with than just the desire of many devlopers and managers to play with (and enhance their street-cred by having experience with) shiny new toys.
Fortunately there are places where the developers and dbas are sensible and the prophet of doom is listened to, as well as places where he's not welcome.
Tom
August 21, 2015 at 12:00 pm
I can understand GenY application developers right out of university wanting to bypass the grumpy DBA middleman and code directly against an object database that they control themselves. The presenters at NoSQL Now 2015 made it all seem so easy and so right.
On the flip side of this debate, maybe MongoDB would be perfect as a temporary shopping cart cache for an eCommerce website or archiving user clickstream data. I don't want them stuffing that fluff in the RDMS either. So long as we all agree that inherently transactional data, the golden data that really matters, belongs in the RDMS.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 21, 2015 at 1:40 pm
I can understand GenY application developers right out of university wanting to bypass the grumpy DBA middleman and code directly against an object database that they control themselves.
I want to bypass the grumpy DBA middleman (and middlewomen), too, and I'm older than the lot of them.
And that's what our shop does - in the development phase. Are you a developer who wants to design your app's database component? Fine, go right ahead and do so. Just know that you'll have to submit your database design to the grumpy DBA for review - and the DBA will get to test your app using the database performance monitor, too.
This makes everyone happy.
The DBA gets to torture and embarrass the app developer. Nothing, but nothing, pleases a DBA more than this.
The app developer learns better database design from the DBA (and receives an object lesson in humility as a side benefit).
The app itself is improved thanks to the DBA's interventions.
The Help Desk doesn't have to answer calls from angry and upset clients about crappy software.
And I get to go on holiday.
August 21, 2015 at 5:05 pm
GoofyGuy (8/21/2015)
The DBA gets to torture and embarrass the app developer. Nothing, but nothing, pleases a DBA more than this.
Not for me. I absolutely love it when code does all the things it's supposed to do (meet/beat requirements, perform well, be readable, and be documented) without me having to get involved other than testing it.
On the other hand, I especially hate developers that practice "malicious compliance" (won't tolerate it) and supposed "senior developers" that have adopted the "ring knockers" attitude or are "too important" to "waste time" to do it right. It brings me no pleasure explaining to such check-valves the way it is and will continue to be.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 21, 2015 at 5:10 pm
Jeff Moden (8/21/2015)
GoofyGuy (8/21/2015)
The DBA gets to torture and embarrass the app developer. Nothing, but nothing, pleases a DBA more than this.
Not for me. I absolutely love it when code does all the things it's supposed to do (meet/beat requirements, perform well, be readable, and be documented) without me having to get involved other than testing it.
On the other hand, I especially hate developers that practice "malicious compliance" (won't tolerate it) and supposed "senior developers" that have adopted the "ring knockers" attitude or are "too important" to "waste time" to do it right. It brings me no pleasure explaining to such check-valves the way it is and will continue to be.
+1000 !
Tom
August 21, 2015 at 5:11 pm
The DBA gets to torture and embarrass the app developer. Nothing, but nothing, pleases a DBA more than this.
Not for me. I absolutely love it when code does all the things it's supposed to do (meet/beat requirements, perform well, be readable, and be documented) without me having to get involved other than testing it.
Sorry, my post was only intended for those who enjoy a little irony, cynicism, and sarcasm.
You're much too pure of heart.
March 3, 2016 at 2:14 am
Too many developers see everything as a shortcut...and I am a developer.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply