Prev: Some help with sort
Next: SBCL optimization
From: MarkHaniford on 15 Jan 2010 20:58
On Jan 15, 6:11 pm, Tim X <t...(a)nospam.dev.null> wrote:
> ccc31807 <carte...(a)gmail.com> writes:
>
> > I've been taken to task (on c.l.p.m.) for saying that many times I
> > just start writing code without doing any analysis or design.
> > Obviously, for a larger project, analysis and design is essential. I
> > think that Graham's point is that analysis, design, and implementation
> > can be integrated with more efficiency and less work. Obviously, you
> > can't build a sizable application this way, but just as obviously any
> > sizable application necessarily contains problems that can only be
> > solved by experimentation.
>
> Analysis is critical because that is how, you as the programmer, get to
> understand the domain problem you will be working in. Design is also
> important, but it should not be carved in stone.
>
> I think PGs main point is that it is often during the implementation
> that you gain that deeper understanding of the problem that provides the
> insight for better solutions and you want to avoid any specification
> that is so detailed that you cannot adopt those better solutions because
> they would not fit with the specification.
>
> I've worked on projects in the past where the specification was so
> detailed, it included all the names of procedures/functions, the
> arguments they would accept and the values they would return. As a
> developer on that project, all you were expected to do was write those
> functions and procedures and at the end, it would all fall together. It
> was an uninspiring, horrible boring project and it was pretty much a
> failure.
>
> I think what PG is talking about is close to what the Agile (God I hate
> that term - bloody weasel word. Lets face it, who the hell doesn't want
> to be 'agile'!) camp has been proposing. Use user stories to get an
> understanding of what is required and then use test driven development
> to not only verify the code and protect against regressions after
> refactoring, but also to verify you as the programmer understand the
> customer/owner's requirements. This is why tests should be developed in
> conjunction with the product owner or representatitve/expert from the
> client side.
>
> Requirements and specifications are all about communication. They are
> there to ensure that everyone knows what the widget is and what the
> widget needs to be able to do. The old waterfall methodology tried to
> make it like dam and bridge building - eveyrthing would be specified
> down to the last bolt and nail. Management would know exactly how much
> it would cost and exactly how long it would take to build (at least,
> they felt reassured they did). This approach
> essentially failed. It failed because it was unable to take into account
> that programming isn't like dam and bridge building. We don't have the
> hundreds of years experience or the relatively well understood laws,
> such as the laws of physics, that engineering in the physical world has.
> Programming has more art than science. The solution often comes with
> understanding and imagination, which is acquired as you attempt to solve
> the problem and will seldom become obvious through analysis alone.
>
> A major point that PG was trying to make is that your development
> environment can assist in this process by making it easier to experiment
> and explore the problem domain. He argues that lisp is one of the best
> languages for doing this and it is why he believes a single lisp
> developer can be more productive than, lets say, a developer using C.
> This theme is also carried through in his other writings. For example,
> he argues that the success of viaweb was because it used lisp and they
> were able to add features faster than their competition. In fact, he
> says that their competition often thought he had spies in their team
> because they would release a new feature and viaweb would have
> incorporated it by the end of that day.
>
> Tim
>
> --
> tcross (at) rapttech dot com dot au

Tim, I might reply to your response in detail later on, but I think
you made some good points. "Agile" has become a religion of its own,
and the whole mission of sitting down with your "customers" and
rapidly banging out mockups has been lost. It's the rapid-feedback
that gave death to waterfall (communication).


Not responding to you Tim, but on another note, nobody in their right
mind would hire anybody that writes Paul Graham type code. It's the
classic, "what happens when Billy gets hit by a bus".

From: Marc Girod on 16 Jan 2010 05:33
On Jan 16, 9:04 am, Tamas K Papp <tkp...(a)gmail.com> wrote:

> That's your problem.

And not the company's you mean?
That's a matter of trade-off. If 'the company'
chooses to hire somebody who matches some
non-programmer's pre-conceptions, rather than
somebody who would write better code, it
should be 'its' problem as well.

I don't like personalizing entities such as
'companies'. In practice, the issue is one of
power inside the company: what expertise is
valued, and what is not. The interests which
get optimized are those of individuals.

> Clearly there are employed programmers.

Sure. But are they employed for what they
really do, or for the perception their
managers (or the HR department) have from it?
How good is the match?

> Whatever.  I am not a job search agency.
> (BTW, these "I challenge you"- type
> utterances must be a clear winner in job interviews).

This remark shows a worrisome asymmetry in
the contractual relationship. Again, such an
asymmetry does not optimize the interest of
-say- the share holders.

> These things are project specific, and are usually decided between you
> and your employer/customer.  Eg if you are writing a library for
> numerical applications, most employers would prefer that you have a
> clear understanding of floating-point arithmetic (eg on the level of
> "What Every Scientist Should Know ...").

You mean, of something *they* don't have...
The risk is this of the urban legend...
I believe concretely ones meets it with GUIs,
which are felt important by people who don't
use them, or comments in the code, by people
who don't read them, etc.
Floating-point arithmetic also shows a
view point, even if arguably a more educated
one.

> But the more you know, the less your customer will have to explain.

Optimizing communications by avoiding it.
I.e. relying upon the fact that it has
already happened: that the knowledge is
indeed shared, relevant, complete...
That's not cutting-edge stuff... No
competitive advantages to be gained.
Is it really relevant to software?

> And the flipside is that if you don't know anything, sometimes
> introducing you to the problem domain is prohibitively costly, so
> people become their own programmers (which happens in science very
> frequently).

Right. That's why Torvalds designed git,
and Behlendorf subversion: because they
felt it was less work to write from
scratch what they perceived they needed,
than to communicate with SCM people.

Marc
From: Frank GOENNINGER on 16 Jan 2010 10:56
fortunatus <daniel.eliason(a)excite.com> writes:

> On Jan 14, 9:46�am, ccc31807 <carte...(a)gmail.com> wrote:
>> In my own job, which requires writing software for lay users, all I
>> ever get is abbreviated English language requests, and I have learned
>> better than to ask users for their requirements because they have no
>> idea what requirements are.
>
> Nobody expects non-programmers to be able to generate programmers's
> requirements.
>
> Programmers generate requirements for themselves based on less formal
> Q&A with the customer.
>
> No matter what, a programmer works to specific requirements that are
> supposed to match the user's expectations and/or needs. The
> requirements might be in the programmer's head, and they might be
> developed by evolutionary process throughout the code writing, but
> they exist. If there is more than one programmer on a team then there
> is a need to codify requirements into documents to some degree.

Yep, that's our (http://www.consequor.de, German language only so far)
experience, too.

The challenge is to capture stuff in a way that clients are able to
recognize their own requirements a few weeks later themselves again. For
this, pictures and diagrams work miracles. Doing those without an
intuitive tool is cumbersome.

We use FlexoBPM not only for requirements capture but also for screen
design and process/screen flow simulation. The tool is able to produce
documentation from captured requirements, too - verryyyy nice !

http://http://www.flexobpm.com/

They call it BPM - but we use it for pretty much everything.

Cheers
Frank

P.S. No, this is not open source software.
From: Frank GOENNINGER on 17 Jan 2010 17:43
Tim X <timx(a)nospam.dev.null> writes:

> Pascal Costanza <pc(a)p-cos.net> writes:
>
>>
>> Customer: "I am the owner of a company, and I want my employees to be able to
>> do their work more efficiently using computers. Can you help me?"
>> Programmer: "So, do you want a word processor or an ABS?"
>>
>>
> Even worse - the customer who thinks they know what the solution is.
> Instead of bringing you the problem and asking if you can solve it, they
> bring you the solution and want you to implement it. You take one look
> at the proposed solution and can see lots that is wrong or just won't
> achieve what the customer wants. Now you have the fun of trying to
> explain to them why their brilliant idea is rubbish and propose
> something better, but of course, 90% of what your tyring to explain they
> don't understand!

Yep. We're seeing this daily. It needs what I call "The Art of Selling
Against Will" which sometimes requires real standing against the
client's statements - even to the point where we step back from an order
refusing to implement against our own convition. Yes, it may sound weird
but it pays off and always forces the client to *think again*.

We just completed a 2000 person day consulting project in which we
redesigned the whole product development processes and their
implementation in SAP and other applications for the client. Client's
initial request: "Could you please upgrade SAP from 3.1 to 4.7 for us?
we just need a pure data migration. The budget is 100 days."

Three weeks and a few CXO level meetings later we had the initial contract
for a PoC of 500 days in our pockets. It did require some heavy
non-technical selling investing in understanding the client's business
model, inherent optimization potential and the levers to achieve the
optimization. Morale: If you want to do it right you have to do
something else right: Selling!

Yes, this project was fun and challenging... We're live since December
30th last year ! :-)

Cheers
Frank
From: Rob Warnock on 19 Jan 2010 03:12
Greg Menke <gusenet(a)comcast.net> wrote:
+---------------
| And whatever your write Shall Conform to several (possibly
| contradictory) coding standards both locally defined and those visited
| upon the world by ISO/CMMI (as mandated by management who doesn't
| actually have to use them). And whatever you do end up coding has to be
| documented according to appendices of the aforementioned standards
| specs, and all changes to it also Shall Conform to the change control
| specs. And when you put your (surviving) code through Validation &
| Verification, the pencil pushers who apply that process have full
| editorial control over your code- from accept to change to reject, and
| are unencumbered by any knowledge, responsibility or accountability for
| the project.
+---------------

Charles Stross <http://www.antipope.org/charlie/blog-static/fiction/faq.html>
does a pretty good job of capturing the insanity of this in his
"Laundry" stories ["The Atrocity Archives", "The Concrete Jungle",
"The Jennifer Morgue", and "The Fuller Memorandum" (due July 2010)].
E.g., exactly how *does* a top-secret intelligence agency deal with
ISO-9002 conformance and outsourced COTS application infrastructure
and audits by the BSA(!) and DRM on essential operational software?!?
;-} ;-}


-Rob

-----
Rob Warnock <rpw3(a)rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Some help with sort
Next: SBCL optimization