Mind Dump - Latest Comments

Re: The difficult definition of professional software development

Tim Ottinger — Tue, 01 Mar 2011 11:15:19 -0000

@ryan:

You say "re: Is a piece of code considered high quality because it's elegant, follows best practices, and so on? Or is it high quality because it does what it was written to do and does not have to be altered in the future."

I agree with two caveats:

I don't believe in "once and for all" for any project people are going to use and maintain going forward. "Easy to understand and change" trumps any "once and for all" in my opinion.

"Does what it is written to do" is a platitude, really. All code operates as it was written. ;-) If the code does something really useful (value to end user) it can be elegant, but of course 60% of all features are never used, so code could be internally elegant and not particularly useful.

So "it does something people need it to do", "does a good job" (performant, etc), and "is easy to change without breaking anything" would be pretty high on my list of qualities for elegant code.

Re: The difficult definition of professional software development

Tim Ottinger — Tue, 01 Mar 2011 11:08:21 -0000

Of course there are contradictory rules. People come at things from different angles. Comments and clean code are both shooting at "readable" in different ways. Inheritance used well will improve extensibility, but used poorly will make the system a mess because it is the strongest dependency. Functional programming is both cryptic and structurally simple (simple and clear are not the some concept).

My take was to try to reach past the practices and approaches and pick out the virtues they're reaching for. It helps me understand different approaches better. http://agileinaflash.blogspot....

I'm not the first to do that, and I may not have done it best, but knowing why people make these statements always helps me to make decisions. I think we all want good product, delivered on a timely basis, and which does not create problems in the future but options instead.

I hope this helps.

Re: The difficult definition of professional software development

Jim Cooper — Tue, 08 Feb 2011 17:51:18 -0000

@Scott

These are worrying questions of yours:

"Is a piece of code considered high quality because it's elegant, follows best practices, and so on? Or is it high quality because it does what it was written to do and does not have to be altered in the future?"

This seems to be an expression of a common meme:

"Just make the code work as soon as you can. It doesn't matter if it's rubbish code because the customer doesn't care about code"

That POV is wrong. The quickest way to get anything beyond the most trivial software in the hands of customers is to write the code well. Crufty code slows you down, sometimes within hours. Write crappy code and that release date will slip. The customer tends to care about that.

Most code also has a long life. You pay dearly when you need to change poor, "quick" code. The customer cares that you can't make changes in a timely fashion and that the software keeps breaking when you try.

Also, I'd like to see how you guarantee code will "not have to be altered in the future". That sort of predictive power would be better used to pick lottery numbers, surely! :-)

By definition, best practices are not things that slow down delivery. If they do, they clearly aren't best practices! (At least not the way they're being done.)

For example. how do you tell your code "does what it was written to do"? Maybe unit testing would help? Or do you think that that is going to slow you down? (If it does, you aren't doing it right.)

All my 20+ years of professional experience in this business tell me that the way to write code the fastest, is to write good quality code.

Customers may not care what the code looks like, but they certainly care about the effects bad code has on them.

Re: The difficult definition of professional software development

gregorylong — Sat, 05 Feb 2011 10:47:29 -0000

@Rayn
Re:I still struggle with what you say about "equally acceptable solutions"
So, as long as we're being very general - e.g. the broadest possible context or no context - then I'm comfortable with this statement. I'm not smart enough to possibly process every realistically plausible context and prove one approach would definitively be better than another.
If we get more specific, put it into an actual context, I'm more inclined to believe the only way two solutions would be equally acceptable would be that they were only slightly different. If I could play back a conversation from work last week I could demonstrate this idea. A co-worker didn't particularly like a solution to a problem and we discussed alternatives. The code in question will be part of an enterprise solution and must be highly flexible. His initial suggestion would require us to a)re-write a portion of a method if our rules for processing changed or b)create a new object for each set of rules. The second choice wasn't too bad except that the application of the rules were only one of the roles of that object.
In the end we arrived with "two equally acceptable solutions":
1)A solution I favored - an abstraction for the role of evaluating and applying rules that depended on an injected collection of rules objects. Rules would be changed by changing the injected collection via our IoC.
2)His favored approach - an abstraction for the role of evaluating and applying rules that explicitly called a known set of rules objects in a know sequence (e.g. hard-coded). Rules would be changed by creating new processing classes that possessed a new sequence.
I liked mine better because we'll have - in my opinion - less code to write when the rules change. But both support the end goal. Mine would fit more closely into the composition, non-functional side of your list but that's where most of my favorite ideas live so . . . meh. I respect my co-worker a great deal and so I'm willing to use his approach if it matters more to him. If we find his solution to be an issue later, it could be rapidly re-factored into mine so . . . why get too wound up about it?

Re: The difficult definition of professional software development

John Sonmez — Sat, 05 Feb 2011 02:00:10 -0000

Perhaps combining most of these statements together creates the clearer picture... Here is my crack at it, I think I have filled in the missing pieces..

Code should always be well commented... one way to do this is to instead have unit tests and well named methods .
Seemingly random class explosion is to be avoided at all costs, but many small simple well named classes are the key to well organized code.
Unit tests really don't test anything useful unless they have a clear purpose are easily understandable and are written in a way to not be brittle.
Using dependency injection everywhere leads to an unusable mess, but Dependency Injection is a very useful tool for making your code extensible and easily reused.
Inheritance leads to solid code reuse, but inheritance is also the strongest coupling of your code you can have, so only use it when composition doesn't make sense.
Functional programming simplifies and minimizes the complexity of your code, but Functional programing can make your eyes bleed, so try to use good naming and simple constructs over doing things "clever".
Static global references are 'just programming' and something you have to learn how to manage to make simple easy to understand code, but Static global spiderwebs are crippling to maintenance and program lifetime so only use them where they make the code much simpler.

Re: The difficult definition of professional software development

Ryan Svihla — Fri, 04 Feb 2011 22:07:07 -0000

@Chad I remember those posts well and if you look back far enough I even commented on one of those posts (pre los techies). This is definitely an area we are in perfect agreement, and truthfully you've helped shape those ideas.

@Gregory Agree about beliefs, people (myself included) carry it too far. However, I still struggle with what you say about "equally acceptable solutions", Who is it acceptable too? From my perspective I'm struggling to understand where the line is to be drawn from "you're going to reap terrible results from this in the future" to "this is acceptable for the way the organization works". There are cases where both are true, does that make it an acceptable way to approach things? Especially when what someone else would call "terrible results" to someone else is "just the way software development works"

Re: The difficult definition of professional software development

gregorylong — Fri, 04 Feb 2011 21:42:11 -0000

@Ryan
re: In reality though most of us get very dogmatic about a particular style we've stumbled onto and hold it for dear life.

I won't even touch the definition of professional software development, but this statement hits what I think may be one of the biggest enemies to improvement in our profession. People have too many beliefs in our business. Beliefs are a crutch, a way to halt our learning process, declare we have found The Truth, and hide our heads in the sand.
It would be better to realize we all just have ideas. Those ideas only have merit if they help us solve the problem at hand. If two different ideas result in two equally acceptable solutions - what's the fuss?

Re: The difficult definition of professional software development

Ryan Svihla — Fri, 04 Feb 2011 18:46:52 -0000

@Scott
re: Is a piece of code considered high quality because it's elegant, follows best practices, and so on? Or is it high quality because it does what it was written to do and does not have to be altered in the future

good questions for thought and I do not have an immediate answer. I've tended to view high quality software as something that behaves as expected. But obviously more often that not software ages out of use. the problem it was solving was no longer as important, or the technology it was written in was "deprecated" so how much engineering is needed is contextual and not really known at the time.

I respect how you're viewing that particular list as a toolkit for a particular project. In reality though most of us get very dogmatic about a particular style we've stumbled onto and hold it for dear life. This makes teamwork and craftsmanship difficult, and occasionally impossible. Now I agree it shouldn't be that way and people should be willing to adapt and adjust, but it's not always the case.

There is just so much more potential for conflict among those that are otherwise capable in their own right than I'm entirely happy about.

Re: The difficult definition of professional software development

chadmyers — Fri, 04 Feb 2011 18:38:49 -0000

A post after my own heart... I've written extensively on this

A Rant on Professionalism
http://www.lostechies.com/blog...

Good Design is Not Subjective
http://www.lostechies.com/blog...

Minimum requirements for "Good" software
http://www.lostechies.com/blog...

Re: The difficult definition of professional software development

Scott DePouw — Fri, 04 Feb 2011 18:28:13 -0000

I think that phrases like this cannot be applied to every situation. Indeed, I tend to think that some of those phrases do not lead to quality code most of the time, but I do respect that they can apply some of the time. I find it difficult to take any of these statements at face value 100% of the time. Sometimes some of the phrases apply; other times the opposite ones do; and all the time it's a varied mix of the phrases that apply to the given situation at hand.

Taken out of context, these phrases don't make any sense when they're all put together like this, since half of them contradict the other half. However, I believe that it takes a good software craftsman to be able to decide which idioms to follow for the project at hand. If someone were to strike up a conversation with one of the above phrases, I would want some good follow-up on why one would say something like that, not simply take it to mean that one would think that it's the end-all be-all mantra to go by.

At the end of the day, what matters is the software produced. Consumers are not going to care how elegantly code was written, if it's under test, etc. They just want they paid for. That's not saying that some of the phrases used above aren't a means to that end. It's simply the fact that the only people that will see the code (barring open source projects, naturally) are the developers. Beyond that, the world merely witnesses the product. Is a piece of code considered high quality because it's elegant, follows best practices, and so on? Or is it high quality because it does what it was written to do and does not have to be altered in the future?

Re: Java IoC containers and classpath scanning (or what I’ve been looking for from .NET for months)

Attila — Sat, 23 Oct 2010 05:33:34 -0000

What you need is GUICE.
http://www.richardnichols.net/...

Re: Java IoC containers and classpath scanning (or what I’ve been looking for from .NET for months)

Karl Kirch — Mon, 20 Sep 2010 11:09:21 -0000

Yeah was wanting to do this recently with a Stripes application I was working on. Ended up looking at how the stripes-guice plugin wired things together. Was ultimately quite pleased with how it all turned out. Just had to annotate the interface to be able to identify it as something my IOC container should be interested in. Props should be given to the Stripes folks though for providing about half of the code needed to pull it all together.

Re: Project Management in Java: A Confused .NET Developer’s Perspective

Ryan Svihla — Thu, 22 Jul 2010 09:13:20 -0000

@Eddie I understand MSBuild is a fuller scripting language, and again I'm not referring to that. Let me put it this way in any of the above things I've covered I've never had to put a [compile.**/*.java]. I have in Ant and **/*.cs in the csc task in NAnt, which again I'm not going over the scripting option but viewing these things as a Project Management format.

Now I'm going to admit I have not used MSBuild for scripting other than the most minor items , so my question is once you've marked that setting will Visual Studio see all included files? For example in Intellij, it has an exclude list instead of an include list (and just a source directory location), if you can get Visual Studio to exhibit that behavior, well awesome and I wish they did that by default, then you could not bother to check in the .proj and .sln files and all and everything would be fine and you could easily have cross version IDE teams, plus it would have prevented TONS of needless source tree conflicts when two people added a different class via the wizard and it added it to the same line in .proj file.

I understand the this is not a straight apples to apples comparison and this is in part what I was trying to highlight in the article. MSbuild is part NAnt and Project Management, and it can be used for both or either. Hence my complete confusion when I entered the Java world.

Re: Project Management in Java: A Confused .NET Developer’s Perspective

Eddie Garmon — Thu, 22 Jul 2010 08:31:53 -0000

Truely speaking, VS project files are MSBuild files, no way around it. You can add a [Compile Include="**\*.cs"] element to do exactly what you are talking about.

Re: Project Management in Java: A Confused .NET Developer’s Perspective

Ryan Svihla — Mon, 19 Jul 2010 11:24:48 -0000

@Eddie
In the article I'm in no way discussing MSBuild as a scripting language at all. You'll note I did not make a mention of Ant. Visual studio does behave the way I have stated. Add a new class, and the MSBuild file created by visual studio aka .proj will actually add a line for that class and where it is located. MSBuild will be called for compilation.

Open up any Java IDE with a directory structure (with no project format) and a Java project for that IDE will be created on the fly and all the libs and .java files will be referenced and added to the compile list. Do the same in Visual and you have a .proj with no files.

Re: Project Management in Java: A Confused .NET Developer’s Perspective

Eddie Garmon — Mon, 19 Jul 2010 11:09:27 -0000

You must not understand MSBuild at all. You can do everything you said a java IDE does, but you must understand its syntax. As far as needing a GUI to edit a build script, they (the GUIs) are only good for trivial tasks in pretty much any IDE. A specialized build file editor (not an IDE) is another story completely.

Re: Project Management in Java: A Confused .NET Developer’s Perspective

Ryan Svihla — Thu, 15 Jul 2010 08:54:03 -0000

@Troy good comments and I appreciate the feedback. Java is nowadays my day job, so I really wanted to dive into it. I at least need to be able to "speak Java" enough to fit in and not have my ideas discounted as "oh it's just a DotNet guy". In the process I certainly dove into waves of competing perspectives and approaches, and most of them not in straightforward comparisons.

Also from a purely language perspective, C# 3.5 was pretty awesome compared to the current state of Java, and from a community point of view I still prefer Alt.Net to anything I've found in the Java community.

End of the day though languages are interesting it's really the interesting people and different perspectives on solving problems that make all of this worthwhile for me .

Re: Project Management in Java: A Confused .NET Developer’s Perspective

Troy — Wed, 14 Jul 2010 23:56:28 -0000

I read your post having somewhat similar hands on experience. It seems clear. But as I read @Senthil Kumar B's comment, my mind quickly traced my path of discovery. And I realized if I didn't have that experience, this high-points-only overview could likely be confusing.

Personally, I appreciated the post as a good overview. But, without personal experience, there's several weeks of discovery in there to follow it.

I've spent about a month in IntelliJ, a few weeks in Net Beans, a week or so in Eclipse. All were good experiences.

Getting one's head wrapped around how dependencies work is very normalized between each IDE. It is mostly a search for where to do the same thing in each particular IDE. My day job is .NET. I'd say, on the whole, that language differences and hardware differences are the biggest factors that steer my preferences. I've only used c# 4 experimentally, but with great pleasure. I feel lost without extension methods in java, but any non-sealed class can be extended to get fluent methods--yet, it's a little more work. It may be my general experience, but I typically find communication between dissimilar boxes less painful in the .NET arena.

Re: Project Management in Java: A Confused .NET Developer’s Perspective

Senthil Kumar B — Mon, 12 Jul 2010 13:46:06 -0000

That was a bit Confusing :(

Re: Come see my Boo talk at Alamo Coders on the 14th

Ryan Svihla — Tue, 13 Apr 2010 16:37:59 -0000

@KevDog
Absolutely, I will post slides and code samples.
We're working on getting video but no promises.

Re: Come see my Boo talk at Alamo Coders on the 14th

KevDog — Tue, 13 Apr 2010 16:25:28 -0000

If it works out, any chance you could post a video of the talk (or slides if you're using them)?

Many thanks,

Kevin

Re: Domain Specific Languages with Boo: AST Macros

Julian Birch — Wed, 07 Apr 2010 15:01:07 -0000

Fair enough, my experience of Boo Macros isn't huge, but I've tried implementing my own, and came to the conclusion that it didn't really have the power I needed (It evaluates before it's done type resolution.) My principal experience is with Binsor, which is great when things are going well, but a nightmare when they're not: figuring out the syntax requires you to read several thousand lines of code...

I still think that diagnostics, in particular, are a serious issue if you ever start to heavily use it. Admittedly, my own argument here is reminding me of the people who told me that they didn't think I should use delegates in my code because people wouldn't understand them...

Re: Domain Specific Languages with Boo: AST Macros

Ryan Svihla — Mon, 05 Apr 2010 22:18:19 -0000

@Julian I think that's a bit extreme as there are well documented problems with every approach, macro's have their place and it's more about tradeoffs.

This case was a simple way to show how it works, please don't take it as a use case, as this was a unit test.

Think of macros as a CLR version of standalone function objects and use them accordingly. They're nice in DSL creation and not something I'd recommend you make heavy use of in general purpose programming.

Re: Domain Specific Languages with Boo: AST Macros

Julian Birch — Mon, 05 Apr 2010 06:58:50 -0000

I'm sorry, it still doesn't strike me that these macros solve more problems than they create. In this case, it strikes me that a base class with a describe method would have been more elegant. If macros get complex, sorting out the compiler errors becomes a nightmare. If they don't, there doesn't seem to be a lot of point. Put it another way: there are an awful lot of well-documented problems with macro programming, and very few of them are addressed by replacing text manipulation with graph manipulation.

I think I probably need to expand on this as well... :)

Re: Domain Specific Languages with Boo: AST Macros

derick.bailey — Sun, 04 Apr 2010 22:44:31 -0000

"the entire subject of what is a DSL and what types of DSL there are and how to create a proper DSL could be a book itself and a fascinating one at that."

yup! http://martinfowler.com/dslwip... :)