High-quality design

[David Peterson]

I wrote up what I said about code commenting in a blog post.

In that post I also claimed that: "High quality design everywhere is like highly optimized code everywhere - very wasteful."

Do you agree?

David

[Nick Novitski]

Well, even code which no one uses, that you immediately delete, acts as practice.  Is practice wasteful?

- Nick Novitski (stuff i've done)

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Peterson]

There's no end to the amount of practice you can do. You can keep writing code then deleting it and trying to do it better, but that doesn't produce much software.

You can almost always improve a design, if you spend long enough thinking about it and tinkering with it. The question is whether those minutes and hours of design effort (and practice) would be better spent elsewhere. There are places where good design can make a huge difference, such as a published API, and where it makes virtually no difference, such as some minor internal implementation detail.

David

You received this message because you are subscribed to a topic in the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/growing-object-oriented-software/6qh_7E0zLGA/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to growing-object-oriente...@googlegroups.com.

[Steve Freeman]

yes and no, I've had to spend a great deal of time (and clients' money) cleaning up those minor implementation details that turned out to be brittle and misleading.

We spend far more time reading than writing code.

S

[David Peterson]

I would say they hadn't been careful about where to spend their design attention.

They hadn't modularized and hidden those minor implementation details behind clean interfaces. If they had you would be able to throw out that code and rewrite it.

I'm not advocating code that is misleading or unreadable. I guess I kind of assumed a base level of quality. I'm talking about where to spend design time beyond that.

David

[George Dinwiddie]

David,

I'm not sure I understand your intent.

On 4/16/13 4:08 AM, David Peterson wrote:
> I would say they hadn't been careful about where to spend their design
> attention.
>
> They hadn't modularized and hidden those minor implementation details
> behind clean interfaces. If they had you would be able to throw out that
> code and rewrite it.
>
> I'm not advocating code that is misleading or unreadable. I guess I kind
> of assumed a base level of quality. I'm talking about where to spend
> design time beyond that.

How would you describe a "base level of quality?" Does this mean
following or ignoring Uncle Bob's SOLID principles?

What does "design time beyond that" include?

Can you offer any examples?

- George

>
> David
>
> On 16 Apr 2013 08:52, "Steve Freeman" <st...@m3p.co.uk

> <mailto:st...@m3p.co.uk>> wrote:
>
> yes and no, I've had to spend a great deal of time (and clients'
> money) cleaning up those minor implementation details that turned
> out to be brittle and misleading.
>
> We spend far more time reading than writing code.
>
> S
>
> On 16 Apr 2013, at 08:42, David Peterson wrote:
> > You can almost always improve a design, if you spend long enough
> thinking
> > about it and tinkering with it. The question is whether those
> minutes and
> > hours of design effort (and practice) would be better spent
> elsewhere.
> > There are places where good design can make a huge difference,
> such as a
> > published API, and where it makes virtually no difference, such
> as some
> > minor internal implementation detail.

--

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[David Peterson]

For me, writing procedural code is significantly faster than writing object-oriented code. My object-oriented code tends to be more flexible, but takes me longer to write as I have to think carefully about the domain, spend time coming up with the right vocabulary and do lots of refactoring to find the "right" partitioning of responsibilities.

When you use interfaces you can mix procedural and object-oriented code. You can have a clean object-oriented core and have relatively procedural implementations behind those interfaces. It's possible to write clear procedural code - i.e. have classes that "do too much" from a strict object-oriented point of view (don't obey SOLID principles - particularly S and O) but are still easy to understand and maintain.

When you get to the stage where those classes are starting to become unwieldy, you can rearchitect / refactor into a more object-oriented design.

Perhaps some people really do "think in objects" and can quickly and easily come up with an object architecture and the right names for classes and objects. If you can't (and I can't - it takes me significant time and effort) then forcing everything to be SOLID and OO is akin to premature optimization. And it's better to invest that energy where it will make a real difference - e.g. the core business model, the higher-level interfaces and public and published APIs.

Does this make sense?

David

--

--- You received this message because you are subscribed to a topic in the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/growing-object-oriented-software/6qh_7E0zLGA/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

[George Dinwiddie]

David,

On 4/16/13 8:23 AM, David Peterson wrote:
> For me, writing procedural code is significantly faster than writing
> object-oriented code. My object-oriented code tends to be more flexible,
> but takes me longer to write as I have to think carefully about the
> domain, spend time coming up with the right vocabulary and do lots of
> refactoring to find the "right" partitioning of responsibilities.

I don't find that to be true. The refactoring happens as a matter of
course. With TDD, I put something where it's immediately easy, get the
green bar, and then refactor it to a place where it should live. This is
easier for me than deciding what is the "right vocabulary" or "right
partitioning." The tests tell me.

>
> When you use interfaces you can mix procedural and object-oriented code.
> You can have a clean object-oriented core and have relatively procedural
> implementations behind those interfaces. It's possible to write clear
> procedural code - i.e. have classes that "do too much" from a strict
> object-oriented point of view (don't obey SOLID principles -
> particularly S and O) but are still easy to understand and maintain.

I don't find chunks of procedural code in an OO system easy to
understand and maintain. When I find them in the course of making a
change, I start extracting things to make it easier, so I can then do
the work I'm setting out to do.

>
> When you get to the stage where those classes are starting to become
> unwieldy, you can rearchitect / refactor into a more object-oriented design.

Yes, perhaps I notice the unwieldiness sooner than you do.

>
> Perhaps some people really do "think in objects" and can quickly and
> easily come up with an object architecture and the right names for
> classes and objects. If you can't (and I can't - it takes me significant
> time and effort) then forcing everything to be SOLID and OO is akin to
> premature optimization. And it's better to invest that energy where it
> will make a real difference - e.g. the core business model, the
> higher-level interfaces and public and published APIs.

No, you do what you can and constantly refactor. I often give things a
particularly bad name, knowing that I'll have a better name in a few
minutes. If I don't, I'll consult with someone else on the name.

>
> Does this make sense?

It makes sense, but it's not what I experience. I test drive core
business models, higher-level interfaces, public and published APIs,
internal interfaces and objects in the same manner. I use Kent Beck's 4
rules of simple design. They're easier (for me) to follow in the heat of
refactoring than SOLID, though they lead to the same place. They helped
me become a better OO developer, and with less work.

It's always a continual process, of course. E.g., as I realize a class
is doing two responsibilities, I'll refactor so it's easier to
understand. The payback is immediate.

- George

>
> David
>
>
>
>

> On 16 April 2013 12:06, George Dinwiddie <li...@idiacomputing.com

> <mailto:li...@idiacomputing.com>> wrote:
>
> David,
>
> I'm not sure I understand your intent.
>
>
> On 4/16/13 4:08 AM, David Peterson wrote:
>
> I would say they hadn't been careful about where to spend their
> design
> attention.
>
> They hadn't modularized and hidden those minor implementation
> details
> behind clean interfaces. If they had you would be able to throw
> out that
> code and rewrite it.
>
> I'm not advocating code that is misleading or unreadable. I
> guess I kind
> of assumed a base level of quality. I'm talking about where to spend
> design time beyond that.
>
>
> How would you describe a "base level of quality?" Does this mean
> following or ignoring Uncle Bob's SOLID principles?
>
> What does "design time beyond that" include?
>
> Can you offer any examples?
>
> - George
>
>
>
> David
>
> On 16 Apr 2013 08:52, "Steve Freeman" <st...@m3p.co.uk
> <mailto:st...@m3p.co.uk>

[David Peterson]

Thanks for your response, George.

I think Kent Beck's four rules apply to procedural code just as much as object-oriented code. It's the SOLID principles which I find take me considerably more design time to adhere to. Finding good names for classes and interfaces also takes me ages. The tests tell you that some collaborator is needed but they don't tell you what it should be called.

I find that at a certain level of granularity, I can often implement a class in a procedural way very quickly without decomposing it further into objects. When I can do that, it's a big time-saver because I don't need to think about all the names. I can always come back to it and turn it into an object-oriented design later if I want to.

If that piece of code is difficult to work with or is changing frequently then I'll refactor and decompose it, but I postpone that until I judge the payback to be worthwhile.

I used to do what you said, but I've found that my productivity has increased significantly by not using OO where I can get away with not using it, i.e. where I do not harm the overall design, only the design of a "leaf node" object.

David

[George Dinwiddie]

David,

On 4/16/13 3:09 PM, David Peterson wrote:
> Thanks for your response, George.
>
> I think Kent Beck's four rules apply to procedural code just as much as
> object-oriented code. It's the SOLID principles which I find take me
> considerably more design time to adhere to. Finding good names for
> classes and interfaces also takes me ages. The tests tell you that some
> collaborator is needed but they don't tell you what it should be called.

I find that Kent's 4 rules drive me toward object-orientedness, because
it's easier to reduce duplication that way. In the first year of TDDing
using the 4 rules, I learned to detect forms of duplication I hadn't
noticed, before. Things like duplication in the order in which things
are done. It made me a better OO programmer.

With refactoring tools, I no longer worry about the names. It will come
to me. Prior to that, I used names easy to replace globally.

>
> I find that at a certain level of granularity, I can often implement a
> class in a procedural way very quickly without decomposing it further
> into objects. When I can do that, it's a big time-saver because I don't
> need to think about all the names. I can always come back to it and turn
> it into an object-oriented design later if I want to.
>
> If that piece of code is difficult to work with or is changing
> frequently then I'll refactor and decompose it, but I postpone that
> until I judge the payback to be worthwhile.
>
> I used to do what you said, but I've found that my productivity has
> increased significantly by not using OO where I can get away with not
> using it, i.e. where I do not harm the overall design, only the design
> of a "leaf node" object.

I guess the answer to your is, "according to your ability." TDD helped
me grok OO, and I was a procedural programmer for a couple decades
before that.

- George

>
> David
>
>
>
>

> On 16 April 2013 19:14, George Dinwiddie <li...@idiacomputing.com

> <li...@idiacomputing.com <mailto:li...@idiacomputing.com>
> <mailto:lists@idiacomputing.__com

> ------------------------------__------------------------------__----------

> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org

> ------------------------------__------------------------------__----------

>
> --
>
> --- You received this message because you are subscribed to a topic
> in the Google Groups "Growing Object-Oriented Software" group.
> To unsubscribe from this topic, visit

> https://groups.google.com/d/__topic/growing-object-oriented-__software/6qh_7E0zLGA/__unsubscribe?hl=en
> <https://groups.google.com/d/topic/growing-object-oriented-software/6qh_7E0zLGA/unsubscribe?hl=en>.

> To unsubscribe from this group and all its topics, send an email to

> growing-object-oriented-__software+unsubscribe@__googlegroups.com
> <mailto:growing-object-oriented-software%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google

> Groups "Growing Object-Oriented Software" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to growing-object-oriente...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[J. B. Rainsberger]

On Tue, Apr 16, 2013 at 4:09 PM, David Peterson <da...@crowdsoft.com> wrote:

Thanks for your response, George.

I think Kent Beck's four rules apply to procedural code just as much as object-oriented code. It's the SOLID principles which I find take me considerably more design time to adhere to. Finding good names for classes and interfaces also takes me ages. The tests tell you that some collaborator is needed but they don't tell you what it should be called.

Perhaps this will help: http://link.jbrains.ca/ovMMvz

 

I find that at a certain level of granularity, I can often implement a class in a procedural way very quickly without decomposing it further into objects. When I can do that, it's a big time-saver because I don't need to think about all the names. I can always come back to it and turn it into an object-oriented design later if I want to.

Most of our generation and those before it learned to think in terms of procedures. I find myself thinking more in terms of interactions among functions, but I still sometimes fall back to thinking in procedures. I grew up thinking in terms of procedures, but until I started practising thinking in terms of objects, and now functions, I decomposed those procedures poorly. I do that better now.

If that piece of code is difficult to work with or is changing frequently then I'll refactor and decompose it, but I postpone that until I judge the payback to be worthwhile.

Sometimes I have good ideas right now about how to decompose it, so I do that. Test-driving encourages me to do that, anyway, since I find it easier to reason about the correctness of several tiny pieces than about the correctness of a single larger piece. If I really have no idea how to decompose something, then I do what I gather you do. I imagine your way gets the job done, and I know my way gets the job done.

I used to do what you said, but I've found that my productivity has increased significantly by not using OO where I can get away with not using it, i.e. where I do not harm the overall design, only the design of a "leaf node" object.

If you still build tiny things and put them together, then object or procedure hardly makes a difference. Objects give us polymorphism and late binding free of charge, but force us to name things (as you've pointed out bothers you). If you write enough procedural code and remove duplication, you'll move in the direction of either objects or composable functions soon enough, anyway. Sounds fine.

Even so, if naming things bothers you, then you might consider practising naming things.

-- 

J. B. (Joe) Rainsberger :: http://www.myagiletutor.com :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

[David Peterson]

It's not so much that I don't know how to name things, it's that it takes me a long time. I think I am probably fussier about names than I should be. I know there are big commercially successful Java frameworks which don't give two hoots about names even in published classes. Maybe I just need to chill a bit, but I find it less mentally draining and faster to avoid naming things when I can get away with it than sit there for what adds up to hours with a thesaurus looking for the right name and metaphor.

--

 
---
You received this message because you are subscribed to a topic in the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/growing-object-oriented-software/6qh_7E0zLGA/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to growing-object-oriente...@googlegroups.com.

[J. B. Rainsberger]

On Tue, Apr 16, 2013 at 5:11 PM, David Peterson <da...@crowdsoft.com> wrote:

It's not so much that I don't know how to name things, it's that it takes me a long time. I think I am probably fussier about names than I should be. I know there are big commercially successful Java frameworks which don't give two hoots about names even in published classes. Maybe I just need to chill a bit, but I find it less mentally draining and faster to avoid naming things when I can get away with it than sit there for what adds up to hours with a thesaurus looking for the right name and metaphor.

I work similarly to George: I feel so comfortable renaming things that I don't worry about naming things. I used to obsess, because I hadn't felt comfortable renaming things. That took time. Now I don't mind renaming the same thing 12 times. It has really helped.

-- 

[Matt Wynne]

On 16 Apr 2013, at 21:00, J. B. Rainsberger <m...@jbrains.ca> wrote:

if naming things bothers you, then you might consider practising naming things.

That sounds like fun. Any suggestions how?

cheers,

Matt

--
http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com

[Alberto Brandolini]

...it also sounds like our brains are essentially black boxes, and TDD and related practices work very differently given the different implementations of our reasoning processes.

Don't know. Maybe that was a really stupid thing to say, but the previous discussion was a kind of eye opener in this sense. 

Alberto

P.S. Sorry, been lurking for a while without introducing myself. And I don't know exactly what my job is, I probably have many. And coding is parto of it.

2013/4/17 Matt Wynne <ma...@mattwynne.net>

--
 
---

You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Raoul Duke]

On Wed, Apr 17, 2013 at 9:57 AM, Alberto Brandolini
<alberto.b...@gmail.com> wrote:
> ...it also sounds like our brains are essentially black boxes, and TDD and
> related practices work very differently given the different implementations
> of our reasoning processes.

reminds me of:
http://www.lagerweij.com/2010/03/16/its-the-people-stupid/

[J. B. Rainsberger]

On Wed, Apr 17, 2013 at 5:01 AM, Matt Wynne <ma...@mattwynne.net> wrote:

On 16 Apr 2013, at 21:00, J. B. Rainsberger <m...@jbrains.ca> wrote:

if naming things bothers you, then you might consider practising naming things.

That sounds like fun. Any suggestions how?

Train yourself to feel comfortable using crappy names in your code. When you sense yourself obsessing, use a silly name. This helps you become comfortable renaming, which perhaps matters more than becoming comfortable naming.

Now, every time you look at that silly name, you'll want to rename it. Go ahead. Now you're practising both naming and renaming.

Repeat.

-- 

[Steve Freeman]

This sounds like the original meaning of DTSTTCPW. Ward talks about doing something obviously dumb and broken when you're not sure what to do next. That helps you make a little progress and breaks the Deer in the Headlights syndrome. Once you've got over the hump, you can fix the obviously wrong implementation.

S

[J. B. Rainsberger]

On Fri, Apr 19, 2013 at 11:13 AM, Steve Freeman <st...@m3p.co.uk> wrote:

This sounds like the original meaning of DTSTTCPW. Ward talks about doing something obviously dumb and broken when you're not sure what to do next. That helps you make a little progress and breaks the Deer in the Headlights syndrome. Once you've got over the hump, you can fix the obviously wrong implementation.

Yup. I adapt from the best.

-- 

[Chris Parsons]

On 19 Apr 2013, at 14:59, J. B. Rainsberger <m...@jbrains.ca> wrote:

Train yourself to feel comfortable using crappy names in your code. When you sense yourself obsessing, use a silly name. This helps you become comfortable renaming, which perhaps matters more than becoming comfortable naming.

Now, every time you look at that silly name, you'll want to rename it. Go ahead. Now you're practising both naming and renaming.

THIS. I can't tell you how much of a breakthrough in my own naming practice I made by allowing myself to call something 'foo' for 10 minutes, or calling a method 'def sort_collection_except_if_already_only_two_things_in_length()' (because that's what it actually did), and fixing the separation of concerns issues later.

Separating the "getting the name correct" from "getting the code design right" in the same move allowed me smaller steps which led to less brain freeze and greater progress.

--
Chris Parsons
chr...@rsons.org
http://twitter.com/chrismdp
http://chrismdp.com

[David Peterson]

Definitely. I don't know how people manage to work with programming languages that don't have an IDE with "rename" functionality. They still fall short, e.g. Eclipse doesn't rename variables properly when you change a class name. That's a pain. But at least it doesn't break the code.

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/growing-object-oriented-software/6qh_7E0zLGA/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to growing-object-oriente...@googlegroups.com.

[Stefano Zanella]

I start with a :vimgrep, then rename the file and pointer where file is imported if I was renaming a class. Surely it's not the fastest method ever, but given my level of confidence on the technique and code at the moment,
it's a good exercise for my brain to give a quick look over the slice of architecture I'm touching.

--
 
---

You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Mike Stockdale]

Learning to do this was one of biggest steps I made in TDD. Seems trivial but really helps.

--
Cheers,
Mike Stockdale

fitSharp
Syterra Software Inc.

[Michał Piotrkowski]

What do you mean by "doesn't rename variables properly"? I haven't experienced this problem. Have you tried Shift + Alt + R, Shift + Alt + R (twice) -> Update similarly named variables and methods?

2013/4/19 David Peterson <da...@crowdsoft.com>

--
 
---

You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Matteo Vaccari]

!!!

Thanks!

Matteo

[David Peterson]

Thanks. It looks like the problem was in my head, not in reality.

Eclipse tip: If you change the rename strategy to "Also find name suffixes", make sure you also choose the option "Update textual occurrences in comments and strings (forces preview)".

I already had "update similarly named variables and methods" selected, but it didn't work for this common situation:

    private TypeChanger<Date> changer = new DateTypeChanger();

Rename TypeChanger as TypeConverter:

    private TypeConverter<Date> changer = new DateTypeChanger();

It hasn't changed the name of the variable from "changer" to "converter" because the name is not an exact match. If it were called "typeChanger" then it would have renamed it successfully. I suppose I could force myself to not abbreviate variable names, but for me that's an undesirable compromise.

Setting the rename strategy to "Also find name suffixes" solves the problem, but it "may lead to unexpected results". You need to review the changes before the rename, and it's easy to forget. However, if you set the option "Update textual occurrences in comments and strings", you can't forget, as it forces a preview.

David

[Steve Freeman]

time to switch to Idea? :)

S

[David Peterson]

It's a getting a bit OT, but is IDEA significantly better than Eclipse or does it just give you a different set of grumbles?

[Steve Freeman]

<religious war>
It's worse at many things, but the refactoring is so much better. My understanding is that IBM cut the refactoring team for Eclipse some years ago and moved on to other things.

I finally got fed up and actually bought an Idea license after the Juno release. Before that I was pretty much bi-ide.
</religious war>

[Matteo Vaccari]

I find that Idea takes considerably longer than Eclipse to start JUnit.  Is it just me?

--

---

You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Colin Vipurs]

I followed the same path.  Long, long time Eclipse devotee but Juno pushed me to Idea, never looked back.

There are grumbles with it but overall it increases my productivity and that's what counts.

--

---

You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

[Steve Freeman]

might be true, but they both take too long. And I do miss incremental compilation.

S

[Brice Dutheil]

It's better in IntelliJ 12, they completely redone the compilation backend, now it almost compiles incrementally. Though it's a bit slower as it delegates some stuff to maven anyway if you are running a maven project.

Also incremental compilation with eclipse is one of the reason of poor performance as it needs to access the drive to write the .class files before, though I'm not sure how it's done now. But clearly on huge project it stresses a lot the harddrive, and if it happens the workstation have a antivirus that don't care about developers  you feel even more the latency when eclipse is compiling and analyzing your class files.

Also, I quite like the inspections in IntelliJ, on today's computer there is almost no performance impact while IntelliJ is analyzing the code you write. And many inspections are really useful for young or even experienced programmers. Complexity, dependencies, size of the code, thread safety, serialization, spring, etc. are some of the covered topics.

Plus there's the share piece of code among your team. Without configuration it identifies the people you can interact with on same project.

Well I find IntelliJ way superior to other tools free or not.

Cheers,

-- Brice