The Whiteboard

12:48 AM

@Bob I haven't used F# for anything significant or practical at all, but I know it a touch and am altogether a big fan of MLs

@Bob It's great for a variety of things; but as a whole it can do everything C# can do; and better, cleaner, with less code

fparsec and type providers are two things worth looking at to see some of the really handy things folks have built in it

or rather, handy things you can use it for

I haven't done anything spectacular with it, just a couple simple utilities

to help in my general work. I've been using the linq 2 sql type provider lately to help get my ORM spun up during development much quicker and easier and more flexible than what I get out of the generated DBMLs in C#

Jimmy Hoffa

1:02 AM

would have saved me some time if I used them longer; after I switched to DBMLs I had a couple bugs I had to debug that were just me forgetting to update the DBML from the schema

Bob

3:45 AM

Hrm...

maple_shaft

11:54 AM

Hey guys... I am reviewing a Best Practices document for Functional Requirements for my new job...

This organization has some serious past failures with SD projects so we are trying to formalize the Common Misconceptions that have permeated the organization about Software Developer in general

I want to make sure that I got everything so if you have any feedback or anything you would like to add then please share

> The programmers work in the industry, so they understand the details of the client’s daily business processes

> The programmers are the ones who will build the application; they are best suited to gather requirements.

> Once the functional specification has been given to the programmers, they are now the owners of this project

> Once the functional specification is approved, the analyst’s involvement in the project is over.

> An Agile development process means I don’t have to write a functional specification. Technical implementation is the most important piece and requirements aren’t strictly necessary to build an application

This is what I have so far based on our post mortem on the disaster projects of the past

The in house business analysts are of extremely poor quality and extraordinarily lazy so I am skeptical this can ever get better without cleaning house, but the directors NEED to read this

It all starts with them

thorsten müller

12:17 PM

@maple_shaft whenever I read such stuff I'm very happy to work in a rather small company.

maple_shaft

@thorstenmüller I tried that... it didn't work out for me

I have a feeling that they are at a point where they finally accepted that what they have been doing for years just isn't working

they are desperate for anybody to stand up and at least TRY to lead them in the right direction

thorsten müller

Yes, I know that situation. Had it when we took over projects from customers that were total failures. Where I work now, I basically took over the whole web site and refactored it step by step. Just it's not that many people, so if something doesn't work I don't write papers but get to the people directly.

I think you get one thing wrong here: You concentrate too much on the failure part and the problems, plus it sounds a bit cynical. Replace every sentence with the solution to this problem would work better maybe.

maple_shaft

@thorstenmüller ty

@thorstenmüller There are long explanations for each of the Misconceptions, I paraphrased for chat

The author is a very jaded and cynical person, he asked me to be the reviewer because I am more level headed and better with language

The document is in the second person... too accusatory. Analysts will read:

> bla bla bla YOU bla bla bla FAILURE

it is better to have

> bla bla bla ONE MIGHT bla bla bla INCREASE RISK

thorsten müller

12:50 PM

Don't know if this is relevant to your situation, but in some cases I found that the underlying problem isn't the software side, but the business processes are already wrong. Example: We have tons of status flags on our products (in stock, can be ordered, show on web site, etc). I got a phone call at least once a week like: Why isn't that on the web site yet?

just to tell them that combination of flag A together with flag B prevents this. So last time they wanted to add another flag I told them to go and straighten that dumb system to a level where they can understand what will happen if they click something. (plus remove all those flags that where more or less textual information.) They use our ERP system like a kind of notepad.

maple_shaft

@thorstenmüller Again... this is the core problem of having ineffective business analysts or product managers.

Management wants the straight truth, they want somebody to take charge, I have plenty of truth to give if they have ears to listen

They have the authority to put more restrictions on what the analysts pass off as a requirements document, and this will have the effect of weeding out and exposing the people who are ineffective

Interesting to note though that their is probably a direct correlation between the tenure of the analyst and the inneffectiveness of their work

Transcript for