|
Kent Sharkey wrote: Besides, don't you still have some code left lying around from your Turbo days (or college)?
Yes. Yes I do.
And I'd say, "and I know how to use it", except I don't. 
|
|
|
|
|
Good code reads well, best code rhymes There once was a coder named Chuck...
|
|
|
|
|
IWandered _lonely As Cloud
if (Music b<Love>(theFood)) { play.On; }
Oh this is going to make an awful mess of Monday...
|
|
|
|
|
Google Glass redux ? The Verge: [^], SlashGear: [^]
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
|
Without altering its genomic sequence, biologists have created hybrid flatworms with heads and bodies from two different species. Good news if you're a brainless worm? (But enough about me...)
|
|
|
|
|
Ah, but Creationism created worms with which science could then do that!
|
|
|
|
|
I'm sure there's a management joke in here somewhere 
|
|
|
|
|
That would imply more another part of the body placed lower 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
What’s the best way to kill the productivity of a software engineering team? Imagine how productive no developers would be!
|
|
|
|
|
It turns out that if n is the number of developers on a project, the number of communications channels between them is n(n-1)/2.
And therein lies the problem with these Agile, Scrum, stand-up, whatever software development practices. Everyone has their hands in the pie. How do you reduce the number of communication channels? By not requiring everyone to communicate with everyone else. How do you do that? By having a crystal clear requirements document. Then you can (theoretically) create teams that consist of smaller teams, etc., parceling out the work based on how the components of project need to communicate with each other to satisfy the requirements. This really isn't that complicated. Decide what needs to be communicated and how.
Now the irony of this is that you are maximizing the communication of components in the application and minimizing the need for communication between developers. Fancy that.
Now, let's look at the opposite situation: Agile development. Here, all the programmers talk to each other, but have you ever seen any attention paid to compartmentalized communication between components of the application? Of course not! What you see instead is a huge OOPS: object oriented programming spaghetti.
Marc
|
|
|
|
|
Personally, I view Agile practices as suited to some types of projects: particularly those where requirements are not known properly in advance, or change rapidly.
The converse is that there are plenty of projects where they do not work well. These typically have hard, known requirements.
The trick is to spot the type of project and adjust your methodology to fit.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
You are right, but he too...
Even when a project change rapidly... if you have 50+ developers, the time waste of communicating with all members is bigger.
It is not a matter of "tree" structure or agile, it is a matter of common sense and middle point using the best of both cases.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Preach it, brother!
I've long observed a direct relationship between the success of a project and the quality of its requirements documents.
|
|
|
|
|
Kent Sharkey wrote: What’s the best way to kill the productivity of a software engineering team?
Cut off Internet.
|
|
|
|
|
Block access to StackOverflow, CodeProject, and MSDN.
Of course, MSDN could be left unblocked with little impact since any useful content it renders is far outweighed by its glut of "off-topic" results, and inane code examples it provides.
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
wrote: What’s the best way to kill the productivity of a software engineering team?
Use C++ 
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
ppolymorphe wrote: Use C++
Apparently, you misread. They were talking about killing productivity, not making it totally awesome.
|
|
|
|
|
The answer is meetings. MVB Anna Majowska focused on what can be done about how meetings impact productivity, and why everyone could use a break. Someone making decaf in the regular pot?
|
|
|
|
|
|
Geographical distribution (especially time zones)
|
|
|
|
|
Not if the team is small enough. 
|
|
|
|
|
 Coincidentally, see next news item (I was just about to add it, even before your comment ).
TTFN - Kent
|
|
|
|
|
Paul Lewis from the Chrome Developer Relations team, thinks the developer benefits of JavaScript frameworks are outweighed by poor user experience. Here's a saw and a tree: go build yourself a house.
|
|
|
|
|
I agree, the horse crap that comes out +5MB worth of frameworks is bad for everyone. JavaScript and the DOM API are growing beyond these wretched frameworks so there is hope.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
