Instead of talking to Slashdot, I think you'd be far more likely to find help speaking to some of your professors. Software development is a strange field, where anybody who grew up with a 386 and a BASIC interpreter can sell their services and offer relatively high value. Ph. D's in computer science tend to have a completely different skill-set from successful developers, and as such their insight into career options isn't frequently as helpful as that of the broader community.
Computational biology, though, is a far more specialized field, and I suspect that your professors will know far more about what sort of problems exist in the field, who is working to solve them, what applications exist for research, etc. You're paying these people, so make use of them outside of the lab / lecture hall.
the more they stay the same. Static code analysis tools are just like smarter compilers, better language libraries, new-and-improved software methodologies, high-level dynamic languages, modern IDE's, automated unit test runners, code generators, document tools and any number of other software tools that have shown up over the past few decades.
Yes, static code analysis can help improve a team's ability to deliver a high-quality product, if it is embraced by management and its use is enforced. No, it will not change the face of software development, nor will it turn crappy code into good code or lame programmers into geniuses. At best, when engineers and management agree this is a useful tool, it can do almost all the grunt work of code cleanup by showing exactly where problem code is and suggesting extremely localized fixes. At worst, it will wind up being a half-assed code formatter since nobody can agree on whether the effort is necessary.
Just like all good software-engineering questions, the answer is 'it depends'.
As a developer, I've noticed that it's all too easy to fall into the trap of surfing the net mindlessly. Sure, it starts innocently at first looking for a solution to whatever bland problem I'm fixing in the code base, but there's the ever present temptation to open a new browser tab and find something of actual interest. The process isn't a lengthy one - only ten minutes or so at a time - but those context switches do add up. I don't mind since I'm salaried and have to be here to hold my chair down, but I know for a fact that, if I were allowed to go home early after putting in the productive 3-5 hours that seem to make up an average developer's programming day, instead of sitting around wasting time, I would do that in a heartbeat. I work in a shop that is transitioning to agile processes, and I am curious as to whether I can make a case for pair programming on this angle. The article doesn't mention this, but I am curious what views the group might have to offer on pair-programming in terms of reduced slack. Unless two people are blatantly unproductive in some sort of bizarre Office-Space conspiracy to steal bandwidth and time, it seems unlikely that the pair will get too far off track. Less time spent ctrl-T'ing your way across the internet through Firefox might equal a shorter workday. Anyone have any thoughts?
I'm not so sure I see this as outrageous or even ill-founded. Unoriginal, perhaps, as all one needs to do is look at the history of computing to see that cycles such as these are well documented. Software-as-a-Service (SAAS) has a certain set of features and characteristics that differs from the features and characteristics of the installed-software paradigm, and I see no reason to suspect that we won't see this cycle continue for at least another few iterations depending on what's 'in' and 'out'.
I think it makes more sense, at least from a developer's standpoint, to look at the various ways to distribute software less as silver bullets and more as tools - like TCP versus UDP. Noone in their right mind would say that UDP beats TCP (or vice versus)in all situations or is the 'wave of the future' - you would choose the right tool for the right job. SAAS makes sense for certain limited applications, like business infrastructure or media-content-delivery, but it would be a terrible choice for something like an OS, or document editing software, or media playback, or games, or...
Slashdot Mirror
Instead of talking to Slashdot, I think you'd be far more likely to find help speaking to some of your professors. Software development is a strange field, where anybody who grew up with a 386 and a BASIC interpreter can sell their services and offer relatively high value. Ph. D's in computer science tend to have a completely different skill-set from successful developers, and as such their insight into career options isn't frequently as helpful as that of the broader community.
Computational biology, though, is a far more specialized field, and I suspect that your professors will know far more about what sort of problems exist in the field, who is working to solve them, what applications exist for research, etc. You're paying these people, so make use of them outside of the lab / lecture hall.
the more they stay the same. Static code analysis tools are just like smarter compilers, better language libraries, new-and-improved software methodologies, high-level dynamic languages, modern IDE's, automated unit test runners, code generators, document tools and any number of other software tools that have shown up over the past few decades.
Yes, static code analysis can help improve a team's ability to deliver a high-quality product, if it is embraced by management and its use is enforced. No, it will not change the face of software development, nor will it turn crappy code into good code or lame programmers into geniuses. At best, when engineers and management agree this is a useful tool, it can do almost all the grunt work of code cleanup by showing exactly where problem code is and suggesting extremely localized fixes. At worst, it will wind up being a half-assed code formatter since nobody can agree on whether the effort is necessary.
Just like all good software-engineering questions, the answer is 'it depends'.
That's just, like, your opinion, man.
</lebowski>
This is Slashdot - leave Lisp puns to reddit and Paul Graham.
Where's the 'whatcouldpossiblygowrong' tag when you need it?
If you're talking about software patents then sure.
The moderators seem to have missed it too (1, undescribed).
At least ones with BO. Maybe we better leave those genes in.
Or nukes.
As a developer, I've noticed that it's all too easy to fall into the trap of surfing the net mindlessly. Sure, it starts innocently at first looking for a solution to whatever bland problem I'm fixing in the code base, but there's the ever present temptation to open a new browser tab and find something of actual interest. The process isn't a lengthy one - only ten minutes or so at a time - but those context switches do add up. I don't mind since I'm salaried and have to be here to hold my chair down, but I know for a fact that, if I were allowed to go home early after putting in the productive 3-5 hours that seem to make up an average developer's programming day, instead of sitting around wasting time, I would do that in a heartbeat. I work in a shop that is transitioning to agile processes, and I am curious as to whether I can make a case for pair programming on this angle. The article doesn't mention this, but I am curious what views the group might have to offer on pair-programming in terms of reduced slack. Unless two people are blatantly unproductive in some sort of bizarre Office-Space conspiracy to steal bandwidth and time, it seems unlikely that the pair will get too far off track. Less time spent ctrl-T'ing your way across the internet through Firefox might equal a shorter workday. Anyone have any thoughts?
I'm not so sure I see this as outrageous or even ill-founded. Unoriginal, perhaps, as all one needs to do is look at the history of computing to see that cycles such as these are well documented. Software-as-a-Service (SAAS) has a certain set of features and characteristics that differs from the features and characteristics of the installed-software paradigm, and I see no reason to suspect that we won't see this cycle continue for at least another few iterations depending on what's 'in' and 'out'. I think it makes more sense, at least from a developer's standpoint, to look at the various ways to distribute software less as silver bullets and more as tools - like TCP versus UDP. Noone in their right mind would say that UDP beats TCP (or vice versus)in all situations or is the 'wave of the future' - you would choose the right tool for the right job. SAAS makes sense for certain limited applications, like business infrastructure or media-content-delivery, but it would be a terrible choice for something like an OS, or document editing software, or media playback, or games, or...