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 | » ]
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 12:46 PM
Reply to this message Reply
Advertisement
> And the second thing is that there are different kinds of
> hacks. There are hacks that can be contained and such that
> spill out into all parts of the system and make it
> unmanagable from the start. It might not be possible to
> replace all the quick solutions in one go or rewrite the
> whole system. So I find it important to enforce at least
> some form of layering or modularization from the start,
> otherwise it might be impossible to gradually improve the
> system later on.
>
> It doesn't take much time to make it clear to everybody
> which parts of the system may or must not depend on which
> other parts. Or things like general exception handling and
> logging principles. If such a general architecure is in
> place, people can start to hack away inside particular
> modules and you can catch most of the spill out by
> properly testing it.
>
I think the general architecture is what's slowing us down now. I want to put into place a general architecture that is high quality, because I'm betting it will make us faster in the future. Since now is the time we're putting these foundational pieces into place, it is taking longer. Once we have the architecture pretty much in place, which may take a year, my hope is that we'll be very fast at making changes and enhancements. That speed is the competetive advantage I'm hoping our extra care and time we're giving our architecture will give us over competitors who hack something out the door quickly.

One of the insights I think I've gotten out of this discussion so far is that perhaps the place for quick hacks is in between the steel girders of the quality architecture, especially if those hacks are well tested. Because even though the hacks may be fragile to the touch, they can work just fine as is. If and when you do need to touch them, the tests will hopefully find most of the problems you create by making changes. Furthermore, at that time, when you actually need to change it, you may decide it is worth it to invest a bit of time to refactor the hack into something higher quality. But the reason that refactor is even possible is because the architecture surrounding the hack is quite solid and supports such changes easily.

Tim Orme

Posts: 3
Nickname: backspace
Registered: Jan, 2004

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 12:58 PM
Reply to this message Reply
This is an excellent discussion with a lot of people making a lot of very interesting and insightful points. It's really caused me to think hard. I offer these thoughts.

> And most importantly, how have you successfully achieved
> quality software at a fast pace in the past? What I'd
> really like to do is generate high quality software as
> fast as any hack. Have you been able to do that?

I believe that creating quality code takes more time, and that there is no way around that. More experience, better tools, better technique, etc can help you increase quality and do it faster, but all things being equal, quality code takes more thought, more effort, more time.

So, (when) to hack or not to hack, that is the question. I think you simply have to weigh the consequences, keeping in mind both the short-term and the long-term. There is often temptation and/or pressure to trade the short term benefits for the long term. It's like purchasing something on a credit card when you don't have the funds right now. It may be worth it for some reason(s) to go into debt to get that item right now, knowing you're going to pay more for it (because of finance charges) than if you waited until you actually had the funds. So it is with software development, with time and effort to create quality being the currency. You can pay up front. If you don't have the "currency" to pay up front, you can take a calculated risk to pay more over time. Just don't cut corners so deeply that you get in over your head.

Mr. Venner's case example was a good one. Corners were consciously cut, but just enough to meet a desired time to market, not so much that functional quality suffered. But now the code is going to be reworked to make it more scalable and, I assume, more maintainable, more extensible. So was it a bad decision to not "do it right the first time"? Not if, as in this case, the rework was planned and the cost was considered acceptable and was outweighed by the benefits.

IMHO, though, I think that time-to-market pressures are sometimes more imagined than real. So code quality is sacrificied for no particular good reason. Ever been on a project where the clients are demanding it in an unreasonable timeframe, and they have to have it by such and such a date, but it's something they've been doing without... well, forever, until now (and there's no obvious window of opportunity that is shutting)?

Again, great discussion.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Rewriting versus Refactoring Posted: Feb 2, 2005 1:27 PM
Reply to this message Reply
> 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

That's a great essay. What we're doing actually isn't a rewrite in the Joel on Software sense. I guess it would be called a "write," because we are doing it for the first time. In the past, we didn't write it, we licensed it. Someone else, Jive Software, wrote it.

When I first started using Jive in 2001, I had the option of using Jive 1.2.4, which was the last open source release, or Jive 2.1, which was commercial, but only cost $100. Jive 2.1 had nicer skins, and I wanted to reward the Jive guys for their hard work, so I paid $100. When I built the features of Artima, such as Weblogs, Buzz, News, Chapters Library, and so on, I built them on top of the Jive API. It has worked out very well, and I would recommend Jive in general.

Our particular problem with Jive is not the past but the future. Artima badly needs to be clustered to deal with growing demand. Jive allows you do to that, but now that costs $8500 for the first server plus $7000 for additional servers. If you have four servers, that's $29,500. Ten servers is $71,500. So my little gesture of sending $100 as a token of my appreciation came back later to haunt me. In the context at the time, I think choosing Jive 2.1 over Jive 1.2.4 was the right decision. I think building the features such as Weblogs on top of Jive was also the right decision at the time. But sometimes one reasonable decision at a time leads you into a corner. And that's what happened here.

We're not planning to replace Jive with a rewrite. Jive will continue to run here forever, but just on one server. What we're planning to do is, as incrementally as possible, move stuff elsewhere and run it on our new architecture. For example, The C++ Source really deserves its own website with its own domain. To do that on top of Jive, I would have to buy another license, because my current license is only for one domain. And it still wouldn't be clustered, which would require even more money. So instead, we're building up a new architecture onto which we will move The C++ Source, and eventually most of the other features of the current Artima. And when that happens, I'm sure we will, as Joel Spolsky put it, astonish people with how few features we have. But in this context, we think it is the right way to go.

Tim Orme

Posts: 3
Nickname: backspace
Registered: Jan, 2004

Re: Can You Write Quality Software Fast? Posted: Feb 2, 2005 2:06 PM
Reply to this message Reply
Eric,
Very thought-provoking! I have some comments:

> When I was coding professionally, I invariably invested in
> long-term designing, bullet-proofing, and "building for
> the future". Invariably, it was a mistake to do so.

> But I can tell you that it
> is almost without exception very wrong to do so -- most of
> the companies I built that software for have long since
> gone out of business.

It sounds like they went out of business for reasons unrelated to your efforts to create high quality software... so I'd argue that that fact does not invalidate at least a thoughful approach to design...

> I can't say I've learned my lesson. I *still* think that
> way. Can't seem to help myself.

A lot of people in our profession are in it at least in part because creating elegant, well-designed code provides a great sense of satisfaction for them. Sounds like you're one.

> So by all means, learn from my mistake. Besides, these
> days I'm totally delighted by the combination of unit
> testing and refactoring. Unit testing keeps my bugs
> shallow, so they're easy to fix. Refactoring lets me build
> elegance into the architecture over time, as needed to
> support new features.
> "organic convergence on elegance"

Very interesting- I like the sounds of it and am sure it works quite well. I guess what I'm arriving at is that this may work in some situations, but not others --> Refactoring, as I understand it, includes changes in component interfaces, which I consider the key element/objective of design. If you're in an environment where you are at liberty to refactor relatively unfettered, then "organic convergence" may be feasible. I'm in a large corporate shop where the business logic components are written by completely different teams than those that write the presentation layer components. And reuse of the business logic components can be across multiple, independently managed applications. So refactoring cannot be done at will. The impacts would be too large. So, in some situations at least, some heavy up-front, forward-looking effort on a design (read set of interfaces) that will be relatively stable is necessary.

David Chazin

Posts: 4
Nickname: dchazin
Registered: Nov, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 2, 2005 9:23 PM
Reply to this message Reply
High quality software certainly can be written quickly. I am a firm believer
that "less" is "more" when it comes to writing software. One thing that having
to be quick does is that it keeps you focused on what is absolutely necessary
instead of worrying about lots of things you "might" need in the future, but
don't. Furthermore, lean code is much easier to re-factor and add features to
because there are less things to get in the way and break. Having done a fair
amount of work maintaining legacy software, you usually find that anywhere from
25-50% of the code is not even used, but was written because someone thought it
might be needed in the future. Some of the best code I've been involved with was
basically designed by 3 of us in a day, coded in 10 days and tweaked as necessary to fix
problems discovered in testing and add new features as required. This software was at the core of a 300
million dollar product line. Furthermore, I have written total hacks (i.e. no
comments, prototype code) that others picked up, found that it worked and put it
into profitable shipping product as is. One common thread, I find with lousy
software projects that usually fail, is that they went through an overly drawn out
design process, so that by the time they got to building something, either the
design premises were out of date or they forgot exactly what they were trying to
do in the first place.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Fast? Posted: Feb 3, 2005 1:32 PM
Reply to this message Reply
Tim Orme wrote:
> A lot of people in our profession are in it at least in
> part because creating elegant, well-designed code provides
> a great sense of satisfaction for them. Sounds like you're
> one.
>
Yes! I'm a lousy engineer. A great artist. Art does not pay. Does not pay. Does not pay. But I'm so wedded to the interal rewards that I can't work any other way!

> > "organic convergence on elegance"
>
> I'm in a large corporate shop where the business logic
> components are written by completely different teams ...
> reuse of the business logic components can be across
> multiple, independently managed applications. So
> refactoring cannot be done at will. The impacts would be
> too large.
>
That's a significant observation. I heartily agree with it. I'll put together two thoughts I expressed in recent posts at this forum (one of which may actually have been on this topic) to explain in a bit more detail:

1) Whereas investing a lot of time to construct the
most beautiful, elegant, and future-proof
architecture is generally wasted, time spent
on designing the interface is not.

2) To me, the term interface covers a lot of
ground. The user has a graphical or command line
interface to the program, sure. But APIs are the
interface to library functionality. And a language
is an interface to computer operations. I spend as
much time as I possibly can on elegance in these
areas.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 3, 2005 1:35 PM
Reply to this message Reply
David Chazin wrote: ...
------------------
Many good arguments for the XP approach! That approach institutionalizes what you have from experience to work.

I guess that's why I liked the Java Style Guide so much--it was a summary of best practices. (I only ever found one thing I disagreed with. And when I tried it their way, I became convinced they had been right all along.)

Denis Krukovsky

Posts: 6
Nickname: dkrukovsky
Registered: Feb, 2005

Re: Can You Write Quality Software Quickly? Posted: Feb 4, 2005 3:02 AM
Reply to this message Reply
Many people confirmed a developer is saving time while taking no care about good design. The point you can go in troubles is when you need a new developer to work on his code.

If I plan my software to be used or extended by other developers in their solutions - I would create well designed software. If I am creating a software library, a framework, or a software platform - I would design it well. I want other developers to study my framework fast and easy - so it should be designed well. If I plan to create a product and then hire another developer to extend it – I need him to spend as little money as possible while learning my solution. So I’ll better design it well.


Denis Krukovsky
http://dotuseful.sourceforge.net/

Krishna Iyer

Posts: 1
Nickname: kiyer
Registered: Feb, 2005

Re: Can You Write Quality Software Quickly? Posted: Feb 4, 2005 5:44 AM
Reply to this message Reply
Phew!Reading through 37 posts of academic brain storming in the software development arena, is indeed exhausting. In fact the lavish spread of jargonry actually made me pretty sluggish in the thought processing...

Anyways, my two cents worth on this thread...
a. The site artima.com is a great site and well built too..
b. Thanks to Bill and Co. for sharing their harrowing moments in deciding and constructing the same..
c. I like XP and do indulge in refactoring as a measure to increase efficiencies and better managing of components too..

Now for my queries and comments...
1. I think the original topic revolved around the how-to and when-to questions that haunt every developper/architect... But somewhere the discussion took a whole bunch of curves leading to many contradictions.. its fine but is the topic getting anywhere ?

2. I am not sure if any of you had the experience of using open source software... There is a GREAT amount of learning in how they are built.. the development processes, the testing and funding etc.. I think, the buisness managers(sponsors) of the project have to decide whether it is worth spending XXXXXX dollars on commercial software or use robust open source software.. I am not saying that open source is better than commercial stuff all the time, but the fact that the entire architecture and the testing is handled by many disconnected individuals, bears testimony to the quality of the software.. As it has been said, there can be many permutations between design, construction and testing.. you can have good design, bad implementation followed by poor testing.. you can similarly figure out the "quality" of the other permutations as well..

3. "Quality" - Ah! I love that word.. but unfortunately, it is a highly subjective matter.. Ask the business, and he will tell u it should be bug free at the end of the day.. Dream on pal about bug free software.. Ask the project manager about quality and he will say it is to ensure that we comply with quality guidelines and processes and pray that his team also believes in those fundas when they implement the solution.. Bottom line it is highly subjective.. One man's quality is another man's pain.. The point here is that as a professional you try to do justice to the project assignment to the best of your abilities and within the time and project guidelines. Beyond that it is anybody's game

4. The single most important point that all the posts missed out is that the business(sponsor) is the key to the project's existence. He specifies what needs to be done for him and at what price.. If after he has done that , the project lead gets ambitious in his head and plans for an utopian solution, well out of budget and timelines, he is asking for mayhem later down. Suitable delivery is dependent on the resources and leeway available for the delivery. Quality is one such compromise along with design. Design for today first but keep in mind the future possibilites in the business functionality domain. Who knows, the enterprise may be history in a few days after you deliver!!!

5. I agree with the MVC advocates.. Keep it simple .. understand the capabilities of the solution env and make design decisions which work within those constraints.. I think design does not have to be sooooo complex a matter.. there are tons of Design patterns book and component based architecture helps to deal with time to market pressures as well as meeting todays functional requirements.. Too much jargonry is killing us all.. simplicity still solves...

6. Finally, the decisions on the key topic, is highly subject to business objectives, funding, capabilites of the team, ambitions,confidence and ability to deliver in the set environment parameters...

I know it is very different than most of the posts here, but hope that common sense may prevail over wishful thinking.. Thanks

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 4, 2005 8:57 AM
Reply to this message Reply
"It's hacking if you don't have automated tests, or don't refactor to improve quality later."

Well then count me a hacker.

Pretty much these days I'm only working in dynamic languages. I code in the debugger and test every single line - generally immediately after I've written it. I get full coverage while I'm developing.

But I don't bother to make all my tests SUnit tests. Its about 5 times as much work and the coverage won't be nearly as good as the manual testing I do while writing.

I think my way produces better code than your way. Here's an example.

I recently interviewed a candidate who insisted on doing xp style development on interview coding questions (on the whiteboard). I spotted a disturbing pattern.

He create a test case. Then wrote code to handle it. I proposed another condition (what if they pass nil) and he added an if block to test for this. I proposed another condition - he wrote another test and added another if block. About 4 of these and he had excessively complex code to implement the function with if blocks to differentiate the cases.

Time to refactor? OK, sure. But this incremental test and write produced a huge amount of rework and lots of code only fit to be thrown away. So I'm not sold on the technique.

Much better to write the code, test it as you go, and move on. I'm glad xp works for you. I've given up on it.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Can You Write Quality Software Quickly? Posted: Feb 4, 2005 3:20 PM
Reply to this message Reply
> He create a test case. Then wrote code to handle it. I
> proposed another condition (what if they pass nil) and he
> added an if block to test for this. I proposed another
> condition - he wrote another test and added another if
> block. About 4 of these and he had excessively complex
> code to implement the function with if blocks to
> differentiate the cases.
>
> Time to refactor? OK, sure. But this incremental test
> and write produced a huge amount of rework and lots of
> code only fit to be thrown away. So I'm not sold on the
> technique.
>
> Much better to write the code, test it as you go, and move
> on. I'm glad xp works for you. I've given up on it.

My experience also is that writing code that changes frequently (what the XP folks would call a "spike solution") is difficult to write in a test-first fashion, because the tests eventually get so complex that they themselves would require tests. So this brings us to the logical impossibility of following the test-first notion completely.

Now, sometimes (quite often, in fact), that spike solution works so well that it can be used, perhaps with some refactoring, in a production system. This happens very often with me. Why would I throw away that completely good, working code, and start from scratch? I just write some tests for it, and then be done it. These days I don't have the luxury of time to throw working code away for any reason.

Jan Ploski

Posts: 8
Nickname: jploski
Registered: Aug, 2003

Re: Can You Write Quality Software Quickly? Posted: Feb 5, 2005 8:55 AM
Reply to this message Reply
> Much better to write the code, test it as you go, and move on.

This works well if neither you nor anyone else is ever going to
touch your code once it has been written (sounds like a
definition of "quick hack" to me). Manual retesting after
changes definitely takes more time and is more error-prone than
running an existing suite of automated (regression) tests.

The simple idea is that automated tests are a long-term
investment; they pay for themselves (only) with time.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Can You Write Quality Software Quickly? Posted: Feb 5, 2005 9:42 AM
Reply to this message Reply
> > Much better to write the code, test it as you go, and
> move on.
>
> This works well if neither you nor anyone else is ever
> going to
> touch your code once it has been written (sounds like a
> definition of "quick hack" to me). Manual retesting after
> changes definitely takes more time and is more error-prone
> than
> running an existing suite of automated (regression)
> tests.
>
> The simple idea is that automated tests are a long-term
> investment; they pay for themselves (only) with time.

Before I heard about JUnit, I used to do unit testing in a similar way that Todd described. What I would do is write some code, then write a small test and run the test with the debugger, stepping through one line at a time and watching. The actual watching of the code executing was very educational, and this technique of testing immediately with the help of the debugger help me make very robust code.

But when I heard about JUnit, I realized that it was basically a way to capture those unit tests I was writing anyway so they can be run again. And that made total sense to me because in meant that over time I was building equity in those tests as well as the code, rather than just in the code. I suspect that the test equity pays off more the larger the codebase and the more people working on it. But if you're writing tests in code, it seems generally worth it to me to put them in a form so they can be run again later.

Since I started writing automated unit tests, though, I don't step through with the debugger anymore. Now I'm wondering why not. It did give me a lot of insight to watch my freshly written code behaving in ways I never imagined while stepping through with the debugger, much more than I feel I get with a simple red bar. If you are already testing with the debugger, I don't see much extra effort involved to actually capture the test so it can be run again later. Then you'd get the best of both worlds.

Curt Sampson

Posts: 21
Nickname: cjs
Registered: Mar, 2004

Re: Can You Write Quality Software Quickly? Posted: Feb 6, 2005 5:18 PM
Reply to this message Reply
First of all, if your test code is getting excessively complex, fix it. I've found that excessively complex code or giving up on something as "untestable" is far more often a reflection of poor developer skills than it is a problem with TDD or XP. The way you make yourself a better developer is to identify and fix the difficult areas. You may have to come back to a piece of code several times over the course of months, but if you persist and use your intelligence, you'll get it cleaned up eventually.

This is one of the good things about having automated tests as well: you can come back to things as you learn more about how to implement them. I've had plenty of bits of code that were pretty nasty hacks, because I just didn't know at the time how to implement something well. Since I have the freedom to rewrite anything at any time, I can come back when I've got an idea for fixing something, try it out, and see what happens. Doing this doesn't generally take very long at all.

I've done the testing by hand thing, and even if I threw away my unit tests after "finishing" the code, I'd still automate the tests. Stepping through with a debugger and examining values is far, far slower than just pushing a button and getting a yes or no answer to the question of whether or not it works. The only thing that makes automated testing slower in some cases is when you don't have a framework for it, in which case you should just invest a few hours in finding and installing one. It will pay itself back in a couple of weeks or less.

Michael

Posts: 12
Nickname: target
Registered: Jan, 2005

Re: Can You Write Quality Software Quickly? Posted: Feb 7, 2005 12:38 AM
Reply to this message Reply
> He create a test case. Then wrote code to handle it. I
> proposed another condition (what if they pass nil) and he
> added an if block to test for this. I proposed another
> condition - he wrote another test and added another if
> block. About 4 of these and he had excessively complex
> code to implement the function with if blocks to
> differentiate the cases.

This was just very bad test case. It is much more better to create several tests than using if/else in a single one. Moreover, I doubt that this guy really used to work with TDD extensively. In most cases tests do not contain any conditional logic.

Michael
http://www.targetprocess.com

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