The Artima Developer Community
Sponsored Link

Weblogs Forum
Can You Write Quality Software Quickly?

59 replies on 4 pages. Most recent reply: Feb 13, 2006 2:27 AM by Vincent O'Sullivan

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 59 replies on 4 pages [ « | 1 2 3 4 | » ]
Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 8:11 AM
Reply to this message Reply
Advertisement
> I didn't feel I had time to do all that. I needed to get
> weblogs out the door, so I just made a few more ugly JSPs
> and got weblogs out the door in three days. The next time
> I needed to add a feature, I went through the same
> decision making process. Next time, same thing, over and
> over until I had a hundred ugly JSPs. Each time I felt a
> hack was the right choice instead of fixing the problem,
> and in hindsight I still think it was the right choice.
> But you can see how the the "bad" architecture propagated
> itself. What I'm trying to do now is pay close attention
> to quality while I'm building a new architecture, so that
> the new architecture will propagate good design.

This fits the "Broken Window Theory" in the "Pragmatic Programmer" by Andrew Hunt and David Thomas. It is normal for "bad" design to propagate itself. The question is how long do you let it propagate before you clean it up. This is where refactoring and TDD (test-first or not) come in. It is designing the code for change and applying that change often.

But you're talking about "bad" architecture. What do you do if you realize you picked the wrong technology (let's say you chose the wrong database or even the wrong language)? That is a tough one. I guess you should start over, but when is the right time is indeed a business decision that may be determined by the market and by your resources.

I'll take my best shot at it though. I would say that ideally (with unlimited resources) you should have one team keep working on the project with the old architecture and another team working on the project with the new architecture. I started my career as a VLSI designer and I worked for a company that will remain anonymous, in a division that was developing microprocessors. That's how new microprocessors were designed.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 8:16 AM
Reply to this message Reply
"Quality" is "value to some person" (or persons)... An inoperative laptop was good enough for an executive, in a story told by Gerald M. Weinberg [probably in the "Quality Software Management" books], because the executive only wanted to look like a power-user, not actually be one.

One could go on to explore short-term quality versus long-term quality. One of the problems in the software industry in general was that software thought to be short-term often ended up being used for decades... and in the focus to deliver quickly, long-term quality practices are often ignored even today.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 9:25 AM
Reply to this message Reply
> It's hacking if you don't have automated tests, or don't
> refactor to improve quality later.
>
> It's XP if you have automated tests, and you refactor your
> code regularly rather than letting it go stale.
>
> I don't hack; I XP.


Hmmm, I don't understand your comment. You can only test something if you know what to test. In other words, it requires extensive domain knowledge. But how do you gain that domain knowledge in the first place? One way is to hold a finger up in thin air and hope that some power greater than us will dictate all that is to be known to us. But another way is to get some functionality out the door, see how users respond to it, get some more or different functionality out the door, etc. That's not an infinite process, however, since, as Bill illustrated, it eventually leads to (a) true domain knowledge, and (b) a huge pile of scary code.

With (b), I found that refactoring only goes so far. At some point, a re-design is required. In hindsight, all that design seems so obvious. But, in reality, all the domain knowledge gained in the process of creating that pile of code was required to now be able to do a good design.

That leads to the notion of development as a non-linear process, with some steps forward and some steps back. But that's a topic for a blog of its own.

For now, I'm just curious - how does refactoring and testing help with that? What does XP say about code that's neither a "spike solution" (because it already is production code), nor a final design, but is sort of a design cul-de-sac?

Dale Kutyna

Posts: 1
Nickname: wavylines3
Registered: Jul, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 9:27 AM
Reply to this message Reply
I have recently begun experimenting with test-driven development. I like the way it shapes the design of the code, without my having to be constantly thinking about what somebody might want to do someday. I am starting to believe that premature abstraction is in the same class as premature optimization, and should be avoided. In our code, we have often guessed wrong about where we should generalize. That ends up costing us more work rather than saving us work down the road.

I think that I have become more productive as I have let go of trying to do grand designs, and concentrated on getting the small design right. One thing I like so far in my short experience with test-driven development is that I can be confident the code is good enough without it being particularly elegant. What might be hacking in one context becomes adequate code as long as it passes the tests.

As far as rewriting applications, a few years ago Joel Spolsky wrote an article about why he thinks it's a really bad idea:

http://www.joelonsoftware.com/articles/fog0000000069.html

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 9:42 AM
Reply to this message Reply
> It's hacking if you don't have automated tests, or don't
> refactor to improve quality later.
>
> It's XP if you have automated tests, and you refactor your
> code regularly rather than letting it go stale.
>
> I don't hack; I XP.

From my reading of XP Explained, it isn't XP unless you do all the practices together, because they depend on each other. If all you're doing is automated tests and refactoring, you're not doing XP, you're just doing P.

Nevertheless, one of the main issues I would take with XP is that it seems to suggest that we mindlessly follow a recipe all the time. It doesn't talk about when and to what extent to do testing and refactoring, or anything else that will help you improve quality. It says, always write a test before you write the code, and always refactor afterwords. I hear echoes of that XP mantra in your post. The when and to what extent question is really what this thread is about. In your experience, when did you feel that you didn't do enough testing or refactoring? When did you feel that you did too much?

In the particular case I described before, where I wanted to add weblogs to Artima and get it out the door fast, I chose to "hack" by writing more ugly JSPs in the way demonstrated by Jive 2.1, which I had licensed. I did it that way because "refactoring" the architecture provided by Jive would have been too costly and time consuming given the business context at the time. In that case, I deemed that writing tests and refactoring would have been exactly the wrong thing to do, and looking back I think that was the right choice.

One of the main things I didn't like about mixing business logic with presentation in those ugly JSPs is that I couldn't test the business logic. Having an MVC architecture gives you not only a nice separation of concerns between business logic (in the controller) and presentation logic (in the view), MVC also enables you to write tests where the return on investment is compelling: the controllers. I was in a situation where I couldn't write tests unless I refactored the architecture, and I needed to get weblogs out the door, so I didn't write any tests.

Luke Hohmann suggested to me that when he's leading a project, he doesn't want people doing any refactoring right before a release. At that time, the reward of refactoring isn't worth the risk that you'll break something that either delays the release, or goes undetected and wreaks havoc once the software gets out in the field. If something needs urgent fixing right before a deadline, you hack it in and get it out the door. But after the release, he puts time in the schedule before starting on new features to do a "post release entropy reduction," which is basically a time to refactor and clean up any messes created to meet the deadline of the previous release. I thought that was really useful advice.

I did eventually start refactoring the ugly JSPs using something Frank Sommers and I called "poor man's struts". At one point I felt it was reasonable to spend a few hours looking around at different MVC frameworks, so we spent that time but just felt that none of them were worth moving to at that point, so we rolled our own extremely simple framework. I had a bunch of URLs that I didn't want to break, such as the URL of this page, so I simply left the JSPs in place, but started pulling business logic out of them into external controller classes. I just called the controller method at the top of the JSP, and pulled the results of the context object returned into variables on the JSP page. The rest of the JSP was the view.

I never finished the process of doing poor man's struts. I usually refactored a JSP with poor man's struts if I needed to do some major editing on it. And while the poor man's struts refactor was an improvement, in truth I still wasn't happy with the result. Even after the refactor, the JSPs were still ugly because they are a mix of Java and HTML, angle brackets and curly braces. I could never keep track of indentation. It was too tempting to mix a bit of business logic here and there in the JSPs despite the presence of poor man's struts. I imagined also that in the future it would be harder to hire web designers to work on the views and Java programmers to work on the controllers if everything could so easily get jumbled together in the JSPs.

A few months ago, Frank and I started not so much a refactor but a redesign. We spent time researching the various MVC frameworks, and once again, decided to roll our own. In great part because of my experience with JSPs, I decided to use Velocity. I think this is the right time to do this redesign, in part because I now have enough experience to know how to fix it. I think had I done a major refactor beforehand, such as replacing the entire set of skins with an MVC framework such as WebWork, I would have just been wasting time.

By the way, the page your looking at was served up, quite effectively, by one of the most ugly, hacked JSPs in our system, flat.jsp, which originally came from Jive 2.1. And it works pretty well.

Eryk Vershen

Posts: 1
Nickname: eryk
Registered: Sep, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 9:53 AM
Reply to this message Reply
"Can you write quality software quickly?" - I find the answer is both yes and no. The parity of the answer depends on the quality of your knowledge of the domain.

If you know the domain well, if you've built solutions for it before then, yes, you should be able to develop quality software quickly because you know what is going to be important. If not, then you will inevitably (unless you are both brilliant and lucky) make mistakes and misjudgements that will either reduce the quality or slow you down or both.

Having done projects with a lot of up-front design and "shooting from the hip" I find that both approaches have their good and bad points. The problem is always the balance. Too much design wastes time specifying many things that are better specified by an actual API, but code often obscures the real problem in a mass of irrelevant detail.

I find that most of the good advice about programming seems to summed up in the epilogue of "Software Tools" (Kernighan & Plauger, 1976):
"Reading and revising are the key words." (Or as we say now - refactoring)
"Controlling complexity is the essence of computer programming."
And their three principles - (1) keep it simple, (2) build it in stages, and (3) let someone else do the hard part.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 10:10 AM
Reply to this message Reply
> Even the best hack is going to deliver better
> quality in more time.
>
Here, though, the test-as-you-code paradigm has a significant advantage. You may be hacking to make things work, but you're still writing tests to be *sure* they work. As a result:

a) You may wind up doing some needed refactoring anyway,
just to make sure things work.

b) The "quality" will be there, in the sense that what
you've written will work.

The process won't be quite as quick as all-out hacking. The testing will slow you down just enough to ensure quality and to ensure that you spend just enough time on the architecture to make sure it supports the features you've developed.

Finally, even though you're not building the grand and glorious architecture of your dreams, you know that you can (should you ever have the time or the need), because you have the test suite you need to be sure of your changes. (In the old days, we "had" to get the fundamental architecture right at the outset, because there was no way we would ever go back to change it--incremental refactoring had not been invented, and the benefits of unit tests were not uet understood.)

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 10:23 AM
Reply to this message Reply
> The main places that are "bad" are JSPs in which a
> lot of business logic is mixed with presentation, and APIs
> that are not at all tested (simply because I was in a
> hurry). But it does I think illustrate that you can have a
> decent user experience with mediocre code quality.
> ...
> When it came time for me to add
> weblogs to Artima, I felt a lot of time pressure to get
> them out the door....so I just made a few more ugly JSPs
> and got them out the door in three days. The next time
> I needed to add a feature, I went through the same
> decision making process. Next time, same thing, over and
> over until I had a hundred ugly JSPs.
>
Aha. There are some choice items to comment on, here.

1. The underlying technology (JSPs) did not easily support
testing.

2. The lack of tests prevented things from getting cleaned
up, so things that started ugly, stayed ugly.

3. Somehow this feels like a different discussion. I think
most of us have been construing "architecture" as the
abstract relationship of things that constitute the
design. We've been thinking in terms of programs. Now
though, we're talking about something slightly different,
it seems to me--not so much "design" as "implementation
choice" -- because the JSP implementation didn't allow
you to migrate to an MVC architecture, yes? (And even if
it did, you wouldn't have the tests to support your
work.)

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 10:36 AM
Reply to this message Reply
> It's hacking if you don't have automated tests, or
> don't refactor to improve quality later.
>
> It's XP if you have automated tests, and you refactor
> your code regularly rather than letting it go stale.
>
That's a brilliant summary, imho. It's a statement of definitions, really. XP feels a lot like hacking, in that you move fast and make changes as they occur to you. But because you're constantly refactoring, you're moving towards elegance, and because you're testing, you're writing stuff that *works*.

And, as Alexander pointed out, you're not creating overly-general code (my weakness!) that never gets used for anything else, ever. (Alexander's other points were good, too--especially with respect to areas that can't be conveniently tested. So far, I haven't seen anyone respond to his "testing isn't always possible" comments. I look forward to the discussion.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 10:39 AM
Reply to this message Reply
> I am starting to believe that premature abstraction is
> in the same class as premature optimization, and should
> be avoided. In our code, we have often guessed wrong
> about where we should generalize. That ends up costing
> us more work rather than saving us work down the road.
>
Bingo. Nicely said. I think I can use that thought to restrain myself. I know that premature optimization is dumb. I learned it the hard way. The concept of "premature generalization" will help me apply that lesson to code abstractions

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 10:55 AM
Reply to this message Reply
> In the old days, we "had" to get the
> fundamental architecture right at the outset, because
> there was no way we would ever go back to change
> it--incremental refactoring had not been invented, and the
> benefits of unit tests were not uet understood.

In the old days, we were not using refactoring and automatic unit tests at all (at least not the way they are used today). You are right that it made us be afraid to change working code and you are right that they are a great contribution to software engineering. But that doesn't mean that now we have to use refactoring and TDD all the time and not do any up-front design and not try to get the fundamental architecture right at the outset at all. Balance, it's all about balance.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 11:05 AM
Reply to this message Reply
> One of the main issues I would take with XP is that it
> ....doesn't talk about when and to what extent to do
> testing and refactoring....
>
> One of the main things I didn't like about mixing business
> logic with presentation in those ugly JSPs is that I
> couldn't test the business logic....
>
> I was in a situation where I couldn't write tests unless
> I refactored the architecture, and I needed to get
> weblogs out the door....
>
> A few months ago, Frank and I started not so much a
> refactor but a redesign. We spent time researching the
> various MVC frameworks, and once again, decided to roll
> our own.
>
I feel your frustration. As with Alexander's comments, you were facing a situation in which testing wasn't practical, so all the advice about how to do things in an ideal world was useless.

The major issue here is technology choice. JSPs don't make testing possible, which kept you in hack-a-matic mode for much longer than you wanted to be there. Velocity with a minimal MVC framework does. Clearly a much better choice.

My take-away messages:

a) Somebody should be marketing that minimal MVC
framework alongside Velocity, and touting it as a
testable way to develop a site.

b) Technology choices are a big deal. Cutovers aren't
easy. And it's hard to make the right technology
choice at the outset, because woeful ignornance is
apparently our lot in life.

c) The orginal question that initiated this thread needs
be rephrased. To, "Is it possible to write quality
code quickly?", I would give a qualified yes. But the
question here is, "Is it possible to write quality
code quickly in an environment that doesn't support
testing and which has no tools for automated
refactoring?" To that, I would have to agree that the
answer is no, and that cutting over to a better
technology is the only option. The questions then
become when and how.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 11:12 AM
Reply to this message Reply
> You are right that they
> are a great contribution to software engineering. But
> that doesn't mean that now we have to use refactoring and
> TDD all the time and not do any up-front
> design and not try to get the fundamental architecture
> right at the outset at all. Balance, it's all
> about balance.
>
Strongly agree. Totally agree. Fully agree.

As I wrote elsewhere on the subject of testing, I design and build in larger chunks, and add tests as I code pieces of the design. It's just easier for me to work that way. I've seen one paper that show how a design that evolved using TDD was better suited to the problem domain than any the designer had thought of originally. That's a great argument for TDD. But it also seems like a lot of work, to me. I like to have a basic design figured out before I start coding. On the other hand, if I had no idea how the architecture should look, TDD offers a useful strategy for building something useful until I know enough to figure it out.

Jan Ploski

Posts: 8
Nickname: jploski
Registered: Aug, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 11:55 AM
Reply to this message Reply
> > I didn't feel I had time to do all that. I needed to
> get
> > weblogs out the door, so I just made a few more ugly
> JSPs
> > and got weblogs out the door in three days. The next
> time
> > I needed to add a feature, I went through the same
> > decision making process. Next time, same thing, over
> and
> > over until I had a hundred ugly JSPs. Each time I felt
> a
> > hack was the right choice instead of fixing the
> problem,
> > and in hindsight I still think it was the right choice.
> > But you can see how the the "bad" architecture
> propagated
> > itself. What I'm trying to do now is pay close
> attention
> > to quality while I'm building a new architecture, so
> that
> > the new architecture will propagate good design.
>
> This fits the "Broken Window Theory" in the "Pragmatic
> Programmer" by Andrew Hunt and David Thomas. It is normal
> for "bad" design to propagate itself. The question
> is how long do you let it propagate before you clean it
> up. This is where refactoring and TDD (test-first or not)
> come in. It is designing the code for change and applying
> that change often.
>
> But you're talking about "bad" architecture. What
> do you do if you realize you picked the wrong technology
> (let's say you chose the wrong database or even the wrong
> language)? That is a tough one. I guess you
> should start over, but when is the right time is indeed a
> business decision that may be determined by the market and
> by your resources.

I just wanted to contribute a link to a paper dicussing the meaning of the term "software architecture". This term is interestingly absent from the XP terminology (mentioned by other posters), which happily assumes that you have already chosen your programming language (how?) and the general engineering approach (how?) before the whole TDD/refactoring fun starts.

http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf

Can you refactor your hand-crafted Perl CGI script collection in a layered J2EE application utilizing off-the-shelf components purchased elsewhere? How about making a switch to a rich client peer-to-peer application written using .NET?

I bet you can do it by refactoring (though one would rather speak of "soft migration" in this context). Will it be as cost-effective as spending some up-front time shopping around and comparing available alternatives? No. These are kinds of decisions typically referred to as "choosing the right software architecture", as opposed to deciding whether to write tests or not.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Tests Help Deal with Complexity Posted: Feb 2, 2005 12:30 PM
Reply to this message Reply
> I've since swiched to XP and, particularly due to the
> test-first developmnt philosophy, have seen the following
> things happen.
>
> Developing entirely new code is slower by a factor of 2-5,
> depending on how much new testing infrastructure you need
> to write for the feature. If it's something where the
> general framework already exists (e.g., adding an entirely
> new web page to a site that already has tested web pages),
> you'll be in the 1.5-2.5 range. If it's something brand
> new, such as adding a database to a website that has never
> connected with one, you'll be at the higher end of that
> range.
>
> Changing existing code is 3-20 times faster, depending on
> how safe you want to be if you didn't have the tests, and
> how sweeping the changes are. I do far more extensive
> rewriting of code (heck, rototilling) than I used to
> because I know the tests will catch the breakage. I do
> experimental rewrites that I could never have done before
> because I had no way of knowing if I'd broken the system
> or not.
>
Thanks. I find these anecdotes about your experience with XP very helpful. I too am a big believer in tests, and in our nextgen effort, I want to make sure somehow that we get very solid test coverage. So far we've done pretty well, but we still need to put into place some tool that gives us a way to measure our coverage. Your last paragraph there reminds me of Kent Beck's discussion of how XP gives you courage to make bold changes, and I think that's a big part of the value of automated tests.

Another way I see tests helping is simply that they help programmers deal with larger amounts of complexity, and that's very important. As hard as we try to keep the stuff we're planning to do at Artima simple, it has a inherent complexity that is somewhat daunting. I think automated tests is one technique that will help us meet the challenge of that complexity. When things get too complex for us to imagine in our minds what the repercussions of our changes will be, the tests can help us discover those repercussions, and address them where need be.

Flat View: This topic has 59 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Attempting to Define Interface Oriented Programming Languages Previous Topic   Next Topic Topic: Collection overused as an argument in Java Libraries?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use