23 Jul, 2009, KaVir wrote in the 1st comment:
Votes: 0
I read an interesting article today: http://www.codinghorror.com/blog/archive...

I'm still digesting it, but it's made me think about how I approach software development professionally compared to as a hobby.
23 Jul, 2009, Sandi wrote in the 2nd comment:
Votes: 0
Catchy title. I think he chickened out, and threw a snowball instead of building a snowman. But, maybe it's a snowball that will start an avalanche.
23 Jul, 2009, David Haley wrote in the 3rd comment:
Votes: 0
I think that almost everything we do always involves some degree of craftsmanship. I think he is exaggerating a little bit; he throws out some caveats about things like size, scalability, purpose, etc., as if they're relatively minor and unimportant. Nonetheless, sure, there is always a form of 'art' to writing good software, and while there are fairly clear and established 'best practices', it often does come down to intuition rather than science.

That said, I'm not sure this is so terribly different from very many other things we do as humans, even things that fall under the 'engineering' label. What bugs me about this article a little is the subtext that CS is somehow particularly different. Perhaps my view is colored from when I learned things, and things might have been different for computer scientists trained in previous decades such as the 1980s.
23 Jul, 2009, quixadhal wrote in the 4th comment:
Votes: 0
It is certainly true that as the level of micro-management on a project goes up, both the productivity and creative solution of problems goes down. While several books on the process of software development make it quite clear that you're much better off getting up and taking a walk through the park while you think about solving a particular issue, middle management is almost always of the belief that if you aren't chained to your desk, you're slacking off.

I really believe they would like to fit all software engineers with keyboards that report the number of keypresses per minute, and let that be your quarterly evaluation. I suspect some of my old bosses might also average in the idle time when the computer is turned off. :)

I agree with David, that CS isn't really all that different from any discipline. It's harder to measure, because unlike mechanical engineering, we don't always have a firm end-goal. Yet it's also not as fluid and free-form as composing music, or writing a novel. Thus, it's not easy to quantify the actual work being done, or progress being made.
23 Jul, 2009, Silenus wrote in the 5th comment:
Votes: 0
I am actually somewhat curious about this. Not being at present a professional developer and more of a hobbyist, I can only based what I know of stuff I have read. It seems to be that perhaps that (perhaps with a bit of hyperbole) what the DeMarco is suggesting is that using engineering disciplines as a model as has been applied in the past is at best problematic. I am curious (perhaps I just missed it) where the subtext is and relationship it has with SE in particular. Perhaps I am too old school and I still view CS not so much as a separate discipline but an amalgamation of an engineering discipline and mathematics. I know as practiced by most researchers it's fundamentally a mathematical discipline more so than engineering one though the reverse may be true in industry (I do not know).

I know that a lot of people seem to be writing about things like XP and Agile development are these sorts of things actually becoming the more prevalent approaches to development? I.e. incremental development, continuous integration, short feedback cycles etc. but I am uncertain how true all of this is in practice.
23 Jul, 2009, Chris Bailey wrote in the 6th comment:
Votes: 0
I believe AP to be quickly making it's way toward replacing traditional approaches. If not across several disciplines, at least in the world of web development. The current trend toward web development as a solution to what seem like non web-related software design challenges supports that initial point as well. In the Rails and Ruby world the general idea is write a story, write a specification based on the story, write software based on the specification. The lenience of the specifications is where it gets interesting, as long as the return values the specification demands are correct, you are in the clear.
Write unit tests to make sure everything is working right, get it working and move on before optimizing it or writing documentation. There is no point optimizing or documenting a piece of code that might change 15 times over the next month. I say (and I am nothing but an amateur hobbyist) just have fun and don't worry so much about best practices and current trends, just program in a way that you enjoy. That's what works best for me, and I'm still having fun with it.
23 Jul, 2009, David Haley wrote in the 7th comment:
Votes: 0
While Chris is correct in one sense, I think people really need to distinguish between talking about enterprise software and hobbyist code. It's not at all often that you can get away with not documenting code when you're working on a more or less large team of developers writing code, even if that code will be changing. When writing code for a business, you can't really "just have fun". It's not to say that it's not fun, it's to say that you can't just do whatever you feel like if you want the group to succeed.

So I think that comments need to be contextualized pretty carefully as being from the professional or hobbyist world.
23 Jul, 2009, quixadhal wrote in the 8th comment:
Votes: 0
Right. Even when I was working for a startup company, the investors want all your t's crossed and your i's dotted. In many cases, the owners are not just looking for new capital, but often looking to sell the product to a bigger company, and nobody is going to buy something that's not fully documented.

That's not to say the folks looking it over will even understand the documentation, but if they ask about a particular module and there's no documentation, that's a big red flag and will often stall or hamper the negotiations.

Blame, like other materials, rolls down hill… and after every manager has passed it along, it will land on one more more of the developers. So, if you saved an afternoon's work by not documenting something that's unfinished, and the investors showed up the next morning, you might be in the dog house and get all the "crap" assignments as your reward.
23 Jul, 2009, David Haley wrote in the 9th comment:
Votes: 0
Well that's a good point in some environments, but I wasn't even going there yet; I was talking about just among the developers themselves, without going to the business side of things; for instance, before shipping, or when writing code that never ships (where I work, we don't write code to sell to other people). When you've got a bunch of people writing code esp. in dynamic languages, the interfaces need to be very clear and you do that with documentation. When you get enough code, you can't expect every programmer to know everything about all modules.
23 Jul, 2009, Silenus wrote in the 10th comment:
Votes: 0
Is it particularly difficult to transition over from doing hobbyist type code -> professional situations? I have been thinking about this a bit recently. I know that certain mud developers probably have walked this path so I am somewhat curious. I believe Descartes might have done this.
23 Jul, 2009, David Haley wrote in the 11th comment:
Votes: 0
That depends entirely on what you did for a hobby. I programmed as a hobby from a very early age onward, got two CS degrees, and transitioned to professional CS. Having done it as a hobby probably helped me, mainly because I had written much more code than people who did something else.

Of course if you write sloppy code for your hobby and don't learn (or choose not to use) good practices, it might or might not be seen as useful in the workplace.

So it depends a lot on what exactly you're doing for your hobby.

In general, I would say that the transition is not necessarily complicated, as long as you can show that you can write good code. Having a solid code sample would help a lot.
23 Jul, 2009, Silenus wrote in the 12th comment:
Votes: 0
I am not sure about others but personally I have been mostly working on C/C++ coding projects. The driver project which utilizes LLVM is one of them. I think I still have a fair ways to go before (personally) I could consider it. My understanding of hardware is still exceptionally poor though I have picked up a number of non x86 devices to attempt to understand the lower level stuff. I am probably a bit sloppier with comments than I need to be but I find that aspect of programming is hard for me to get a handle on personally. The range of different styles that people use vary a lot.
23 Jul, 2009, Chris Bailey wrote in the 13th comment:
Votes: 0
David Haley - At in the general case of Rails development (and of course during the development cycle) the specification or story itself is referred back to and considered documentation. An example.

require 'player'
describe Player do
it "Should have strength 10 at creation." do
plr = Player.new
plr.strength.should == 10

As long as the code is meeting the specification, nothing else matters throughout early development. The Player class is effectively documented through the various specifications that is must meet. As long
as you cover every aspect through your specification (which should be done before you write a single line of code for Player), you are good.

the Player
class Player
attr_reader :strength
def initialize
@strength = 10

In order to make our specification pass, the only thing we require is that we can create new Player objects, that they have a strength variable equal to 10 after creation, and that
it is accessible from outside the class. So we our now meeting specifications and we know exactly what our player class can do. Dumping all of the specification out into text for
reading is a simple process as well.
Writing a "story" is higher level than the specification. An individual skilled in writing stories will sit down with the client to discuss the features they require in their software. The story
will write out in a very simple to understand way (for non programmers). Giving a sample story isn't quite as easy for me (I don't use them and they are pretty detailed). Suffice it to say
that they are a very specific DSL and pretty cool. Cucumber is an new story system and should answer any questions you have! =)
23 Jul, 2009, David Haley wrote in the 14th comment:
Votes: 0
Maybe your examples are a little too simple, but I'm not really seeing how they would help me understand large, complex modules that implement lots of business logic, mathematical operations, access to databases and aggregation thereover, etc.

Also, I'm not sure if this was a response to the comment about needing to distinguish hobbyist programming vs. enterprise programming? It's still interesting, I'm just not sure if we were talking about the same thing. :tongue:
23 Jul, 2009, Chris Bailey wrote in the 15th comment:
Votes: 0
I was talking about how professional Ruby/Rails developers using BDD/TDD and Agile/XP practices typically document their code during development phases. The example I provided is about as simple as it could get but hopefully you will take my word for it that it scales very well. =)
23 Jul, 2009, flumpy wrote in the 16th comment:
Votes: 0
Chris Bailey said:
I was talking about how professional Ruby/Rails developers using BDD/TDD and Agile/XP practices typically document their code during development phases. The example I provided is about as simple as it could get but hopefully you will take my word for it that it scales very well. =)

"Scalability" is a very misused term… code written in an agile way simply will not scale very well without good software engineering principals applied before hand, even if those principals are not formalised in UML but in your head. Most programmers cannot do this very well, believe me, because I've seen the results.

Sure you might get something that works, but thats different from being scalable. Generally, agile code gets the job done, but when you need to revisit and refactor as in most systems you will need to rewrite most of it unless you have forseen, at least in a very limited way, the need for change. This foresight cannot be learned, it is picked up over years and years of doing the same thing over and over, and recognising where this can happen. Not to say you cannot read or try to understand these principals, but where you apply them takes experience.
23 Jul, 2009, Chris Bailey wrote in the 17th comment:
Votes: 0
When I spoke of Professional developers I was making the assumption that a Professional will have the foresight required to do their job correctly. =)
23 Jul, 2009, David Haley wrote in the 18th comment:
Votes: 0
That's a big assumption. Don't forget that a central tenet of so-called "agile" programming is to not spend much time on foresight at all. Write code now, refactor later. That's kind of the whole point of the methodology, actually.
23 Jul, 2009, Chris Bailey wrote in the 19th comment:
Votes: 0
That is the whole point of it but it doesn't mean you can't write your code intelligently. That would put Professional agile developers on the same level as myself really, which would be pretty sad for the industry =(
23 Jul, 2009, Runter wrote in the 20th comment:
Votes: 0
An 'agile' programmer would be a polite insult in some circles.