What he says sounds good in the abstract, but I worry about how it will be implemented. For instance he raises the issue of licensing people to practice computer science. However as he acknowledges that it is difficult to even identify who should be in charge of deciding what should be tested for such a license.
And that is a big issue. A license created to meet the needs of business 40 years ago would certainly have required learning COBOL. A license created 20 years ago would have no relevance to web development. One created today would likely be geared towards the needs of large organizations with large code bases - which would put most agile development techniques, languages, and practices off the table.
For better or worse the programming world has diverse communities with rapidly changing, diverse needs, and no possible solution has any hope of fitting all of them.
Licensing is an afterthought to his main thesis. His main point is that we have to remove the disconnect between industry and academia. Both parties take pride in being completely separate from one another. This has to end, and that is a cultural change, something that is completely within the realm of doing in less than 10 years.
As for the relevancy of licensing, I think there is a certain degree to which one could start certifying software engineers on a project management perspective, because the principals of how one approaches a project and brings it to completion aren't that different from any other project in any other industry. If you're running your project correctly, programming is maybe 10% of the project. That other 90% has a lot to learn from the rest of the industrial fields to catch up and start adopting standard practices.
A user's requirements are going to be the same no matter what programming language you use. The way you test the software is going to be the same no matter what programming language you use. Within a specific programming paradigm, how you build the software is a shear matter of syntax, all the parts are going to have to be the same. Just as you can have a suspension bridge versus a stone bridge, I think you could study object oriented programming versus functional programming, and I don't see any reason why we shouldn't expect professional, licensed software developers to know both.
COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and iron. The principles haven't changed much at all.
I think there is a certain degree to which one could start certifying software engineers on a project management perspective, because the principals of how one approaches a project and brings it to completion aren't that different from any other project in any other industry.
Huh?
Project management on a website that has an incremental 1 week release cycle has no relationship to project management of an internal database upgrade that is planned for 6 months or project management for developing a shrink wrapped game over 2 years.
The problems, documents, workflow, problems, types of people you need involved, etc are radically different in these three cases.
A user's requirements are going to be the same no matter what programming language you use. The way you test the software is going to be the same no matter what programming language you use. Within a specific programming paradigm, how you build the software is a shear matter of syntax, all the parts are going to have to be the same.
I disbelieve.
I've been in a situation where I was creating a reporting system, and was sitting in a group of people building a website. There was absolutely no similarity in requirements, testing, rollout procedures, and turnaround expectations between me and the other developers. This despite the fact that we were working in the same organization, on projects specified by the same product managers!
As for a specific programming paradigm comment, the statement seems to me to be vacuously true because you define "paradigm" to include the internal structure of the software, or else false. Because I've seen many cases where two people deliver essentially the same functionality using the same basic toolkit, but the internal organization, pieces, etc are completely different.
COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and iron. The principles haven't changed much at all.
Huh? COBOL doesn't even have recursion. C has function pointers but no closures. C# has closures but no Lisp style macros. Clojure has all of the above. The capabilities of the languages are different, and therefore the proper design and structure of software is as well.
Also where principles have not changed, people's understanding of them may. For instance take test driven development. It isn't new - when Larry Wall delivered Perl 1 in the mid-80s it came with a reasonably complete test suite. When CPAN was founded in the mid-90s the whole perl Makefile.pl, make, make test, make install routine was already standard. And the result was that Perl got a good name for being portable in practice.
However as recently as a decade ago you'd have been hard pressed to find many advocating a test driven style of development. Problems existed that it would work well for. Useful enough tools existed for people to take advantage of them. But there wasn't wide spread acceptance of that knowledge.
Today if you are a programmer and don't know the basics of unit testing, you need some remedial re-education. And a lot of organizations don't use it.
In short unit testing today is where source control was in the late 90s which is where structured programming was in the 80s. It is a good idea. It is widely recognized to be a good idea. But it is a good idea that is more honored by the breach than the observance in your average programming shop.
The problems, documents, workflow, problems, types of people you need involved, etc are radically different in these three cases.
How so? In the web site case I need a person who can code and person to do art/design. In the instance of a game guess what I need a person who can code and someone to take care of the art and design. The only real difference seems to be a matter of scale. Every project in the software development world consists of two things content and code.
The capabilities of the languages are different, and therefore the proper design and structure of software is as well.
Hey guess what the properties of wood iron and stone are just as different and require different designs or do you think the sears tower could have been made of wood with out a change in its design?
You really think that the only thing you need to produce a shrink wrapped game that is in production for 2 years is someone to code and someone to take care of art and design? And you really don't understand why I would say that project management on that project is very different than project management on a website that delivers incremental revisions every week?
Sorry, but you clearly have some things to learn. Go pick up http://www.amazon.com/Software-Project-Survival-Guide-Practi... and learn what a stand alone project on the scale of that game needs to do just to have a reasonable chance of success. Virtually none of that book applies to the incrementally developed website.
Oh, and don't forget that the game has no chance of success without a lot of non-software work such as licensing and marketing.
Comments
What he says sounds good in the abstract, but I worry about how it will be implemented. For instance he raises the issue of licensing people to practice computer science. However as he acknowledges that it is difficult to even identify who should be in charge of deciding what should be tested for such a license.
And that is a big issue. A license created to meet the needs of business 40 years ago would certainly have required learning COBOL. A license created 20 years ago would have no relevance to web development. One created today would likely be geared towards the needs of large organizations with large code bases - which would put most agile development techniques, languages, and practices off the table.
For better or worse the programming world has diverse communities with rapidly changing, diverse needs, and no possible solution has any hope of fitting all of them.
Licensing is an afterthought to his main thesis. His main point is that we have to remove the disconnect between industry and academia. Both parties take pride in being completely separate from one another. This has to end, and that is a cultural change, something that is completely within the realm of doing in less than 10 years.
As for the relevancy of licensing, I think there is a certain degree to which one could start certifying software engineers on a project management perspective, because the principals of how one approaches a project and brings it to completion aren't that different from any other project in any other industry. If you're running your project correctly, programming is maybe 10% of the project. That other 90% has a lot to learn from the rest of the industrial fields to catch up and start adopting standard practices.
A user's requirements are going to be the same no matter what programming language you use. The way you test the software is going to be the same no matter what programming language you use. Within a specific programming paradigm, how you build the software is a shear matter of syntax, all the parts are going to have to be the same. Just as you can have a suspension bridge versus a stone bridge, I think you could study object oriented programming versus functional programming, and I don't see any reason why we shouldn't expect professional, licensed software developers to know both.
COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and iron. The principles haven't changed much at all.
I think there is a certain degree to which one could start certifying software engineers on a project management perspective, because the principals of how one approaches a project and brings it to completion aren't that different from any other project in any other industry.
Huh?
Project management on a website that has an incremental 1 week release cycle has no relationship to project management of an internal database upgrade that is planned for 6 months or project management for developing a shrink wrapped game over 2 years.
The problems, documents, workflow, problems, types of people you need involved, etc are radically different in these three cases.
A user's requirements are going to be the same no matter what programming language you use. The way you test the software is going to be the same no matter what programming language you use. Within a specific programming paradigm, how you build the software is a shear matter of syntax, all the parts are going to have to be the same.
I disbelieve.
I've been in a situation where I was creating a reporting system, and was sitting in a group of people building a website. There was absolutely no similarity in requirements, testing, rollout procedures, and turnaround expectations between me and the other developers. This despite the fact that we were working in the same organization, on projects specified by the same product managers!
As for a specific programming paradigm comment, the statement seems to me to be vacuously true because you define "paradigm" to include the internal structure of the software, or else false. Because I've seen many cases where two people deliver essentially the same functionality using the same basic toolkit, but the internal organization, pieces, etc are completely different.
COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and iron. The principles haven't changed much at all.
Huh? COBOL doesn't even have recursion. C has function pointers but no closures. C# has closures but no Lisp style macros. Clojure has all of the above. The capabilities of the languages are different, and therefore the proper design and structure of software is as well.
Also where principles have not changed, people's understanding of them may. For instance take test driven development. It isn't new - when Larry Wall delivered Perl 1 in the mid-80s it came with a reasonably complete test suite. When CPAN was founded in the mid-90s the whole perl Makefile.pl, make, make test, make install routine was already standard. And the result was that Perl got a good name for being portable in practice.
However as recently as a decade ago you'd have been hard pressed to find many advocating a test driven style of development. Problems existed that it would work well for. Useful enough tools existed for people to take advantage of them. But there wasn't wide spread acceptance of that knowledge.
Today if you are a programmer and don't know the basics of unit testing, you need some remedial re-education. And a lot of organizations don't use it.
In short unit testing today is where source control was in the late 90s which is where structured programming was in the 80s. It is a good idea. It is widely recognized to be a good idea. But it is a good idea that is more honored by the breach than the observance in your average programming shop.
The problems, documents, workflow, problems, types of people you need involved, etc are radically different in these three cases.
How so? In the web site case I need a person who can code and person to do art/design. In the instance of a game guess what I need a person who can code and someone to take care of the art and design. The only real difference seems to be a matter of scale. Every project in the software development world consists of two things content and code.
The capabilities of the languages are different, and therefore the proper design and structure of software is as well. Hey guess what the properties of wood iron and stone are just as different and require different designs or do you think the sears tower could have been made of wood with out a change in its design?
You really think that the only thing you need to produce a shrink wrapped game that is in production for 2 years is someone to code and someone to take care of art and design? And you really don't understand why I would say that project management on that project is very different than project management on a website that delivers incremental revisions every week?
Sorry, but you clearly have some things to learn. Go pick up http://www.amazon.com/Software-Project-Survival-Guide-Practi... and learn what a stand alone project on the scale of that game needs to do just to have a reasonable chance of success. Virtually none of that book applies to the incrementally developed website.
Oh, and don't forget that the game has no chance of success without a lot of non-software work such as licensing and marketing.