Quantcast

Maximum PC

It is currently Fri Dec 19, 2014 9:39 am

All times are UTC - 8 hours




Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: our industry as a whole
PostPosted: Tue Sep 07, 2010 8:30 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Since we're on this topic, I have been reading (well, more like reading excerpts) from the book "Rework" by DHH and Fried.

http://37signals.com/rework/

What do you guys think of this book? If you've read it, share your thoughts and if not, read the excerpts (they're pretty interesting).

My takes (based on the excerpts, so I'll comment on what I've read so far):

- The chapter of workaholics and meetings is powerful. Coming from big corp, my day to day was full of meetings. To me, meetings are an utter waste of time. Why bother with it when I could be writing code and be productive? Also, the chapter of workaholics was a bit of a shock. They're purporting that we only work 9-to-5 (or 7-to-3:30 in my case). That, honestly, is where my attention was caught. I've been pulling 50 to 60 hour weeks prior to my vacation in July and, honestly, it was tiring. I felt guilty because I felt that my vacation came in the way of the team's progress but I really did need a vacation. Instead of managing the project (because we're not an Agile shop), we had spent more time in meetings and documentation than coding.

- The chapter on "Planning is Guessing" is interesting. I've never seen documentation that lived up to 100% of the product it's describing. I'm starting to fall into the philosophy of "you're documenting something because it's inefficient." This couldn't be anymore true in my work now; our overall architecture is so complex, we have to document everything. It's frustrating because I decomissioned 3 servers and recommissioned 2 new boxes - all of which are SQL Server boxes - and now, my documentation is out of sync with reality. I have to spend HOURS fixing/updating it. I'm literally guessing that in the future, our systems won't change - and it will! Also, I had spent so much time documenting an app I'm writing that I think 60% of the app has changed since the original document was created.

What say you?


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Tue Sep 07, 2010 8:37 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24238
Location: Granite Heaven
DJSPIN80 wrote:
- The chapter of workaholics and meetings is powerful. Coming from big corp, my day to day was full of meetings. To me, meetings are an utter waste of time. Why bother with it when I could be writing code and be productive? Also, the chapter of workaholics was a bit of a shock. They're purporting that we only work 9-to-5 (or 7-to-3:30 in my case). That, honestly, is where my attention was caught. I've been pulling 50 to 60 hour weeks prior to my vacation in July and, honestly, it was tiring. I felt guilty because I felt that my vacation came in the way of the team's progress but I really did need a vacation. Instead of managing the project (because we're not an Agile shop), we had spent more time in meetings and documentation than coding.


I hate meetings. Particularly meetings that involve anyone who isn't working on the project at hand. If we need to translate X into layman's terms so they understand it, they shouldn't have asked the question.

Quote:
- The chapter on "Planning is Guessing" is interesting. I've never seen documentation that lived up to 100% of the product it's describing. I'm starting to fall into the philosophy of "you're documenting something because it's inefficient." This couldn't be anymore true in my work now; our overall architecture is so complex, we have to document everything. It's frustrating because I decomissioned 3 servers and recommissioned 2 new boxes - all of which are SQL Server boxes - and now, my documentation is out of sync with reality. I have to spend HOURS fixing/updating it. I'm literally guessing that in the future, our systems won't change - and it will! Also, I had spent so much time documenting an app I'm writing that I think 60% of the app has changed since the original document was created.


This is where Agile comes in. I can alter docs on-the-fly as the project changes and my docs are always accurate as a result.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Tue Sep 07, 2010 11:50 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Productivity in all of Corporate America, not just programming related professions would see an increase in productivity from increased vacations and optimized meetings, IMO. I know I play catch up when coming back from vacation, but I am pretty good at filtering and getting caught up in a couple days after a week off. It is nice to get away and clear the mind. You come back refreshed and stronger.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Tue Sep 07, 2010 6:16 pm 
Northwood
Northwood
User avatar

Joined: Sun Jul 15, 2007 6:37 pm
Posts: 2261
Location: No. 1 Thread Killer
Just give me a 40-hr week and weekends off and I think i'll be a good, refreshed worker every day.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Tue Sep 07, 2010 11:19 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
Jipstyle wrote:
Note: it is possible that I'm a slavedriver and my teams deliver because I crack the whip .. I haven't lead a non-agile writing team and I'm not interested in taking contracts from companies that don't use Agile dev processes. During the interview process, I quiz the team leads and PMs to ensure that what they implement Agile processes rather than just brag about them.

Actually, I've found that asking technical questions is an excellent way to feel out a team. There have been 5 or 6 instances where my administrative boss(es) has asked me to "interview" for an internal position. In all of the interviews, I've probably been asked 3 to 5 technical questions! I get really nervous about working for a team when the 3 or 4 people at the interview manage to ask no worthwhile technical questions. Will Robinson -- DANGER -- These idiots don't know $hit.

At a couple of the interviews, when asked if I had any questions for their team, I decided to ask them technical questions in disguise. Questions just to see if they even recognized some common terminology. The one guy that actually did ask me a couple of technical questions apologized in advance for asking. Stupid lame teams... =\


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Tue Sep 07, 2010 11:27 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
Gadget wrote:
Not to be a pita academic who actually reads what people post (including myself), this link has nothing to do with the effectiveness of Agile developement! It is clearly about the incompetence of managers in Enterprise environments, and how they pretend to adopt agile methods.
Understood. :)

That was part of the point though... it seems everybody thinks it is awesome, but "nobody" really does it.

Well, "this is an interesting point on why agile doesn't seem to work" probably wasn't the best choice of words as it leaves people with the impression that agile development methodologies are to blame when it is the pointy-haired bosses causing most of the failures.

Forgot during the last post... what's with Jipstyle and these SCRUM references... it has to be a Canadian thing! =)


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Tue Sep 07, 2010 11:51 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
DJSPIN80 wrote:
Since we're on this topic, I have been reading (well, more like reading excerpts) from the book "Rework" by DHH and Fried.

http://37signals.com/rework/

What do you guys think of this book? If you've read it, share your thoughts and if not, read the excerpts (they're pretty interesting).

My takes (based on the excerpts, so I'll comment on what I've read so far):

- The chapter of workaholics and meetings is powerful. Coming from big corp, my day to day was full of meetings. To me, meetings are an utter waste of time. Why bother with it when I could be writing code and be productive? Also, the chapter of workaholics was a bit of a shock. They're purporting that we only work 9-to-5 (or 7-to-3:30 in my case). That, honestly, is where my attention was caught. I've been pulling 50 to 60 hour weeks prior to my vacation in July and, honestly, it was tiring. I felt guilty because I felt that my vacation came in the way of the team's progress but I really did need a vacation. Instead of managing the project (because we're not an Agile shop), we had spent more time in meetings and documentation than coding.

- The chapter on "Planning is Guessing" is interesting. I've never seen documentation that lived up to 100% of the product it's describing. I'm starting to fall into the philosophy of "you're documenting something because it's inefficient." This couldn't be anymore true in my work now; our overall architecture is so complex, we have to document everything. It's frustrating because I decomissioned 3 servers and recommissioned 2 new boxes - all of which are SQL Server boxes - and now, my documentation is out of sync with reality. I have to spend HOURS fixing/updating it. I'm literally guessing that in the future, our systems won't change - and it will! Also, I had spent so much time documenting an app I'm writing that I think 60% of the app has changed since the original document was created.

What say you?

Are you starting a soap box company or what?! =)

You have no idea how bad documentation can be until you've worked on a DOD project. It effin amazing how much stupid, pointless, documentation is done for no other reason than to spend federal tax payer money. One of the medium sized teams that I worked on has a... honestly, I forget what they called this stupid document... of course, the acronym started with an S and ended with a D. Anyways, this particular document was something like 500 pages long (if not more). There was an appendix at the end of the document that contained a couple hundred flowcharts. I had done a comprehensive review of the code (grade = pathetic) and realized that NONE of these flowcharts were in the code... not one of them! And to top it off, many of the flowcharts didn't even do what they were supposed to do (ie things like parse integers from strings correctly). It was unbelievable.

Of the 16 to 20 Word docs that supported this product, I would estimate that 50% of the material was a combination of standard boilerplate (title page, proprietary info, sometimes DOD info, revision history, index (yeah, don't get me started with that... argh). There was hardly any real content; Mostly just "pointers" between the various documents -- the SRD says that you can find info on xyz in the SAD or the SPD or the STD and possibly the SID -- and, of course, each of those documents stated that you can find xyz in some other document. In hindsight, it was as if every supporting document was a node in a compete directed graph.

Part of the problem is that our mostly delusional bosses believe writing more documentation is actually better than say finding and eliminating duplicate or smelly code, writing unit tests, trying to prove that a tricky bit of code works (or doesn't work). Hell, as you almost suggested, eliminating documentation would often be an improvement. Out of date and/or misleading documentation is worse than having to look something up in the code.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 4:55 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Jipstyle wrote:
This is where Agile comes in. I can alter docs on-the-fly as the project changes and my docs are always accurate as a result.


To me, code is truth. Code speaks for itself (assuming ceteris paribus; that the developer had in mind the future and used good code standards and styles), I never believed in technical documentation and the only documentation I only believed in was with regards to the work being done. I like Agile's concepts of "user stories" where a function point is described. To me, user stories makes sense because it captures the essence of the work that needs to be done.

I've worked on VERY large systems and never once did I read the documentation (because it was over 1,000 pages in size), but I found that code is discernable and with pair programming, it helped me ramp up faster. Some of the best documentation I wrote involved technical documentation; documenting the changes with regards to a user story. That made sense to me, as a user story and the underlying technical changes are mapped out.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 5:07 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Gadget wrote:
Are you starting a soap box company or what?! =)


hehehe! :) No, not really but it makes for a nice discussion. The whole Agile debate, reading that was fun. It's good to see developers getting lively, nerding out and discussing what matters to us. After all, we are some of the most creative people in the world; exercising both sides of the brain and developing things that cannot be touched, and in some respects, understood.

Quote:
Part of the problem is that our mostly delusional bosses believe writing more documentation is actually better than say finding and eliminating duplicate or smelly code, writing unit tests, trying to prove that a tricky bit of code works (or doesn't work). Hell, as you almost suggested, eliminating documentation would often be an improvement. Out of date and/or misleading documentation is worse than having to look something up in the code.


I sometimes think that those MBA brass ruined software engineering as a profession. I worked for a BIG bank, and I worked on their large, software system. I've never written so much documentation in my entire life as I did for that bank. I wrote so many, I felt physically ill. Meeting after meetings - it was, by design, the worst time in my life to be a programmer (but they did have good benefits).

One of our main protests was that the system was too complex to maintain and too complex for what it really does. If we had been given the opportunity to refactor huge portions of the app, it would have increased its overall performance, stability and decreased the cost of maintenance. Management didn't want to do anything and wanted to merely leave a paper trail; so the old guard remained and, as a result, the good dev's started jumping ship. All that documentation proved more to be an exercise in wasting hard drive space than benefiting the code; heck, our BA's were so behind that they were at least 3 releases behind.

In the future, as I progress in my career track (i.e., I'm currently a lead developer working my way to a more senior status), I would love to see the death of documentation in projects I work on.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 6:05 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24238
Location: Granite Heaven
DJSPIN80 wrote:
Jipstyle wrote:
This is where Agile comes in. I can alter docs on-the-fly as the project changes and my docs are always accurate as a result.


To me, code is truth. Code speaks for itself (assuming ceteris paribus; that the developer had in mind the future and used good code standards and styles), I never believed in technical documentation and the only documentation I only believed in was with regards to the work being done. I like Agile's concepts of "user stories" where a function point is described. To me, user stories makes sense because it captures the essence of the work that needs to be done.

I've worked on VERY large systems and never once did I read the documentation (because it was over 1,000 pages in size), but I found that code is discernable and with pair programming, it helped me ramp up faster. Some of the best documentation I wrote involved technical documentation; documenting the changes with regards to a user story. That made sense to me, as a user story and the underlying technical changes are mapped out.


:roll:

How often do I hear this crap from devs? Code is truth. :lol:

So what do you do when you're hiring contractors to write modules for customers and you don't want to expose your code base to them? Or when you're hiring a contract dev for 4 months .. do you really expect them to learn your code-base by reading the code? And do you think it is an efficient use of resources to assign a dev to pair with them?


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 7:49 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Jipstyle wrote:
So what do you do when you're hiring contractors to write modules for customers and you don't want to expose your code base to them? Or when you're hiring a contract dev for 4 months .. do you really expect them to learn your code-base by reading the code? And do you think it is an efficient use of resources to assign a dev to pair with them?


The whole point of web services (at least REST in this case) is to prevent outsiders from seeing your code base. If I had to hire a contractor to write modules for customers, yes, I would only expose REST interfaces (or some sort of interface) that only they could use. I would seriously expect them to learn by reading the code, yes. Pair programming isn't a waste of resources, it ensures that new hires or contractors get up to speed quick. I want accountability for my contractors; their contractual status is dependent on how hard they worked and how quickly they picked up the code. Pair programming gives me the advantage of contractors who 1) don't know what they're doing 2) take their sweet, sweet time (and they do) and 3) helps them ramp up quickly.

Let's just say I've worked with a LOT of contractors. Prior to my being hired on, my boss hired a contractor to write software for us. It's buggy as heck, it barely covers 70% of what the documentation requires and it costs more money to have it fixed. So I'm a little squirrelly about contractors, to me, they're just in it for the money.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 7:53 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24238
Location: Granite Heaven
Just in it for the money ... as opposed to?

If you want to bring people up to speed quickly, well-written documentation is second only to dedicated trainers. Trainers are a salary-cost resource as are your devs. Docs, once written, are not. The idea that proper docs for new hires and contractors, including descriptions of architecture, interfaces, best practices, etc., is not worthwhile is one of those annoying 'head-in-the-sand' myths that appear to be omnipresent and unsupportable.

I argue this point every six months. In the end, I make money for the companies I work for by freeing resources in the long term, drastically reducing ramp-up time for new hires and contractors and increasing code quality, reusability and extensibility. You'd be shocked at how poorly enterprise projects are actually understood by the principals in the majority of workplaces.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 10:32 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Jipstyle wrote:
Just in it for the money ... as opposed to?


Meaning that the contractor's main goal is to work as many hours as possible, so if a four month contract can become six months, more money for them.

Quote:
If you want to bring people up to speed quickly, well-written documentation is second only to dedicated trainers. Trainers are a salary-cost resource as are your devs. Docs, once written, are not. The idea that proper docs for new hires and contractors, including descriptions of architecture, interfaces, best practices, etc., is not worthwhile is one of those annoying 'head-in-the-sand' myths that appear to be omnipresent and unsupportable.


Documents, once written, needs to change and it needs to change as quick as the software grows. The idea behind Agile are quick releases, I've seen Agile releases go as quick as two weeks. With that being said, it's difficult to free up resources to maintain documentation. I'm not advocating trainers, I'm advocating pair programming. Pair programming passes knowledge between programmers more efficiently and a set of eyes between driver and observer ensures that the contractor (who's driving - or typing) has with him at all times an observer who understands the system, the work that needs to be done. That, to me, is worth more than any documentation (I've been far more productive when paired with a senior programmer who guided me to understanding the system).

Quote:
You'd be shocked at how poorly enterprise projects are actually understood by the principals in the majority of workplaces.


Been there like you, but I found that when I paired up with someone to tackle a problem, we were far more productive and, well, twice as knowledgeable. :P We had fewer bugs and, in the end, turned out a much better design than if he or I tackled it alone. I've been in too many orgs where we spent a lot of resources documenting than spending time building out correct programs. I've never been a big fan of the traditional model but there are times where the traditional, old school methods work.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 10:49 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24238
Location: Granite Heaven
DJSPIN80 wrote:
Documents, once written, needs to change and it needs to change as quick as the software grows. The idea behind Agile are quick releases, I've seen Agile releases go as quick as two weeks.


See all of my previous comments regarding documentation and writing within an Agile environment.

Quote:
With that being said, it's difficult to free up resources to maintain documentation.


If by 'freeing up resources' you mean having devs do the documentation ... you're already doing it wrong. Devs have no more idea how to accurately and efficiently document a system (any system) than a writer does how to design and develop software. 'Information architect' isn't just a fancy title that nets a 6-figure salary. :P (Though, fancy titles do help during financial negotiations).

Quote:
I'm not advocating trainers, I'm advocating pair programming. Pair programming passes knowledge between programmers more efficiently and a set of eyes between driver and observer ensures that the contractor (who's driving - or typing) has with him at all times an observer who understands the system, the work that needs to be done. That, to me, is worth more than any documentation (I've been far more productive when paired with a senior programmer who guided me to understanding the system).


I suspect you haven't worked with a decent doc set, then. I'd also point out that documentation doesn't excluse pair programming .. in fact, it works best with it. The senior pair can always say 'don't forget to use X rather than Y in case Z .. see the docs for a complete explanation' and go back to work.

When I'm designing docs, I often sit in on pair meetings to see what knowledge is transferred. This is exactly the knowledge that needs to be captured and made as intuitively available as possible to free up the time of the senior (and most expensive) dev.

Quote:
Quote:
You'd be shocked at how poorly enterprise projects are actually understood by the principals in the majority of workplaces.


Been there like you, but I found that when I paired up with someone to tackle a problem, we were far more productive and, well, twice as knowledgeable. :P We had fewer bugs and, in the end, turned out a much better design than if he or I tackled it alone. I've been in too many orgs where we spent a lot of resources documenting than spending time building out correct programs. I've never been a big fan of the traditional model but there are times where the traditional, old school methods work.


Still not sure why you think that docs exclude pairs ... but they don't. They extend them. They are an additional knowledge base rather than an exclusive one.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 11:11 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Jipstyle wrote:
I suspect you haven't worked with a decent doc set, then. I'd also point out that documentation doesn't excluse pair programming .. in fact, it works best with it. The senior pair can always say 'don't forget to use X rather than Y in case Z .. see the docs for a complete explanation' and go back to work.


Well, I just haven't worked in an environment with a decent documentation anything, ever. :P It's part of my bitterness towards documentation. ;P

Quote:
When I'm designing docs, I often sit in on pair meetings to see what knowledge is transferred. This is exactly the knowledge that needs to be captured and made as intuitively available as possible to free up the time of the senior (and most expensive) dev. Still not sure why you think that docs exclude pairs ... but they don't. They extend them. They are an additional knowledge base rather than an exclusive one.


I may have missed it in an earlier post but clarifying matters. If documentation extends the knowledge between paired dev's then I'm all up for it.

BTW, I started this post with the intent of ranting but it turns out, it's a good avenue for how other devs in this forum work. It's kind of interesting reading through and debating topics. Let's keep this going! :D


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Wed Sep 08, 2010 9:24 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
Regarding documentation, I think that both of you have made good points. First, there needs to be some documentation. Here are the things that I think documentation can help with...

1) At a minimum, I need to know what the code is supposed to try and accomplish.
2) I would like to get a 10,000 and 50,000 foot view of the system.
3) Having good "javadoc" style documentation is important for libs and utility code.
4) Having some kind of record of what approaches were considered/tried and any current problems is also handy.
5) The user obviously needs a manual or help system.

Of course, these are just goals and getting them right is often hard.

Pitfalls:
1) This can span from being as vague as a company brochure to a very detailed requirements document. I don't think either extreme is very useful.

2) In a changing system, I don't want to actually "write" this up (unless it is small). Tools need to be able to create this view. The problem is that managers tend to think exclusively in a top-down manner... design and doc first, dev later.... whereas most good devs tend to work in both a top-down and bottom-up manner. Of course, it is always interesting to see people's reactions when the expected and actual design don't match up!

3) The pitfall here is that I've often seen devs create code that should go into a library, but they don't want to do this because then they have to document the code, deal with increased bug reports, etc. Not having a good utility library available is almost always a sure sign of horrible systems/code/devs.

4) People are often reluctant to document their failures. However, knowing what approaches were tried to solve a problem is often a good way for deciding on a new approach w/o reinventing the wheel or giving you some additional information to put you further along. Scientists often state that they build upon each others work... more devs need to do this.

5) I really wish they'd just hire Jipstyle to do this!


Of course, the problems with documentation are just enormous:

1) Projects that spend way too much time up front on documenting everything. The goal is to create a system/program that includes documentation. Often, we get this 180 degrees wrong and basically have a whole bunch of documents and a broken system because people are spending too much time doing things like figuring out how to create an index instead of actually thinking of better ways to solve a problem.

2) Managers that insist on using a fixed process for the documentation. Create this document, then that document, then this document... everyone is stuck in this cookie cutter mental box. Different projects require different types of documentation. Duh!

3) The law of diminishing returns applies to documentation. Too much documentation not only wastes time and provides less utility (if you can't find what you need or aren't willing to read through the tomb, what good is it), but it also makes developers hesitant to change the code in a positive manner. It often sucks up time that could be better spent on prototyping or some other useful work.

We can certainly take a lesson from science. Some wisdom from the very quotable Dr. Feynman:

Quote:
For example, if you're doing an experiment, you should report everything that you think might make it invalid — not only what you think is right about it; other causes that could possibly explain your results; and things you thought of that you've eliminated by some other experiment, and how they worked — to make sure the other fellow can tell they have been eliminated.


Quote:
How To Solve Unsolvable Problems

The best lecture I recall started out with Feynmann suggesting that he stop the course, because it wasn't really getting anyplace. Then he decided to talk about what he was doing right then, as an example of real research. He was interested in quantum chromodynamics, and the big frustration at the time was that people had a theory, but it was too difficult to evaluate it and predict numerical results of experiments. He explained that in cases like this, it was hard to know where to start. He wanted to "understand" aspects of the theory, and develop intuition. For example, asymptotic confinement (quarks seem to bind together more tightly as you pull them apart).

He told us that he approaches these issues by rehearsal. 'Think of a simpler problem that seems similar. If you can't solve that, think of a simpler one. If you can solve it, then SOLVE IT. Don't just say you know how to solve it. After that, you might think of a way to attack the harder problem. You might realize something.' Basically, keep poking around and give your intuition a chance to develop and wait for ideas to pop into your head.


Top
  Profile  
 
 Post subject: Re: our industry as a whole
PostPosted: Sun Sep 12, 2010 3:06 pm 
8086
8086
User avatar

Joined: Wed Jun 09, 2010 7:18 pm
Posts: 98
Make sure you post that paper on Maximum PC. It sounds interesting. :D


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.