The Artima Developer Community
Sponsored Link

Weblogs Forum
Architecture the Accelerator

59 replies on 4 pages. Most recent reply: Mar 5, 2005 8:49 AM by Isaac Gouy

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: Architecture the Accelerator Posted: Feb 23, 2005 6:44 PM
Reply to this message Reply
Advertisement
> > I make the following statements without supporting
> > argument.
>
> Frank Sommers wrote: "That's interesting, because that
> statement sounds like a hallmark of a religion."

>
> Bill Venners wrote: "These are the kind of statements
> filled with religious fervor that give me the impression
> of XP as cult."

>
> There are many religious folk who are deeply thoughtful.
>
There are indeed.

> In contrast we might say that these statements are an
> expression of dogma.

However you may decide to put it, I hope this discussion doesn't digress into debates about the pros and cons of religios fervor, but rather stays focused on the substance of the debate. I am speaking from my experience about code quality, but I also find I learn a lot by hearing about the experiences of others, and I have gotten a lot from the writings of Uncle Bob. I suspect he is expressing the sentiments he wrote about in his weblog post "We Will Not Ship Shit":

http://www.artima.com/weblogs/viewpost.jsp?thread=7588

I also get the feeling Uncle Bob is frustrated that anyone would suggest that anything less than the utmost code quality is OK. While that is a noble ideal, I find it doesn't fit business reality. I have had this communication problem before. At the Writing Better Code summit I attended a couple years back, there were some folks for whom I have great respect that just didn't seem to have any idea what I was talking about when I referred to estimating return on investment of quality. Like Uncle Bob, they felt there was no excuse to ever produce less than optimum code.

My observation is that sometimes business people don't appreciate the business value of quality code, that you do get a return on investment long term for demanding and paying for quality code in the short term. But on the other hand, I find that sometimes developers don't understand the business value of time to market, of meeting deadlines even with a mediocre product.

Dilbert paints a picture of marketing people as baffoons, and we all laugh and nod our heads. We complain that the deadlines imposed on us are arbitrary, but don't appreciate that meeting an arbitrary deadline that was promised to a customer has a lot of value. It really does. The date you get your paycheck every two weeks is an arbitrary deadline, for example. How would you feel if your check was late because the check writing software was using the purple font instead of black? Most people would rather get checks with purple font on the deadline than wait a week to get checks with black font. The timeliness of that check, and the ability to deposit it, are the main aspects of quality that you probably care about.

Todd Siegel

Posts: 7
Nickname: tsiegel
Registered: Mar, 2004

Re: Architecture the Accelerator Posted: Feb 23, 2005 7:24 PM
Reply to this message Reply
> My observation is that sometimes business people don't
> appreciate the business value of quality code, that you do
> get a return on investment long term for demanding and
> paying for quality code in the short term. But on the other
> hand, I find that sometimes developers don't understand the
> business value of time to market, of meeting deadlines even
> with a mediocre product.

Uncle Bob and Frank were discussing what is means to be a professional, but I think Bill found it. It is the programmer that can balance technical and business concerns while delivering value to his customer. But it's much deeper than sacrificing code quality to get the job done. Sometimes it's a negotiation. When a deadline is getting close, I'd rather cut scope than cut quality. If I can deliver 80% of the original product, with only the bells and whistles missing, I've delivered value to the business today. I'll finish the rest tomorrow.

I can sleep a lot better knowing I cut a few extraneous requirements and kept quality high. Of course, in the real world of tight deadlines, maybe a hack or two gets thrown in. But the point is that quality should not be the first thing to go.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Architecture the Accelerator Posted: Feb 23, 2005 8:03 PM
Reply to this message Reply
> However you may decide to put it, I hope this discussion
> doesn't digress into debates about the pros and cons of
> religios fervor, but rather stays focused on the substance
> of the debate.


Mr Martin brooks no argument. He spake!

> I am speaking from my experience about code
> quality, but I also find I learn a lot by hearing about
> the experiences of others...


Aren't we talking about a subset of those ole non-functional requirements, those qualities like - extendability, maintainability, portability, reliability...

> My observation is that sometimes business people don't
> appreciate the business value of quality code, that you do
> get a return on investment long term for demanding and
> paying for quality code in the short term. But on the
> other hand, I find that sometimes developers don't
> understand the business value of time to market, of
> meeting deadlines even with a mediocre product.


Maybe no one's accounted the $ business value of quality code to said business people?

Maybe the said business people did the sums - iirc software development with Ada has lower lifecycle costs than C++, but that doesn't matter because so many projects are cancelled before we pay the full lifecycle costs.

Maybe the business people are used to discussing which quality levels they think are appropriate for a product. Other roduct development groups use QFD and the House of Quality to make trade-offs across different qualities.

And Tom Gilb www.gilb.com promoted similar ideas in software development.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Architecture the Accelerator Posted: Feb 24, 2005 12:03 AM
Reply to this message Reply
> When a deadline is
> getting close, I'd rather cut scope than cut quality.

There's a grave danger of falling into a meaningless semantic arguments. Only the programmer cares about the 'quality' of the code. Everyone else cares about the 'quality' of the product. They would say that if you have cut the scope of the product then you have, per se, cut it's quality. They would (quite rightly) rather see a working product with bad code than an partial product with perfect code.

The word 'quality' sounds great when making belocose statements, but when examined closely becomes vague to the point of meaninglessness.

Vince.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Architecture the Accelerator Posted: Feb 24, 2005 12:54 AM
Reply to this message Reply
> An architecture that is right for today, is wrong for
> tomorrow.

That's an extremely sweeping generalisation that, without evidence to back it up, is worthless. Much better to say:

An architecture that is right for today may not be the most appropriate one for tomorrow. (We don't know it will be wrong because we're not predicting the future, right?)

> Architectures are transient things that support
> where we are now rather than where we think we
> might need to go.

OK, we shouln't design for tomorrow but for today.

> To support change, an architecture must be changeable.

So we do design for the future, after all.

> This means that it must be very well written, simple, and
> d elegant.

It's better if it is, worse if it isn't. A sliding scale, not black and white. In any case the terms 'well written', 'simple' and 'elegant' mean different things to different people, so are of very limited use. For instance, patterned code can be all these things but if the reader isn't aware of the presence of a pattern then the same code is simply obscure and obtuse. i.e. These qualities are properties as much of the programmer as of the code itself.

> Such an architecture does not predict
> the future. Rather it adapts to the future by
> being easy to change; and by hiding the agents of change
> from the application.

Architectures don't predict and they don't adapt. They just are. Programmers do these things. It's primarily the ability of a programmer that determines if the code can be adapted. By attributing motives and actions to the code we therefore end up blaming the code for being wrong.

> For example, an architecture that is designed around J2EE
> entity beans is hard to change. The system running within that architecture is bound to the J2EE APIs almost
> inextricably.

Absolute agreement. Here, a sweeping generalisation is appropriate. All EJBs are an abomination and the spawn of the devil. In fact I'd go further but there may be children present.

> On the other hand an architecture that uses J2EE, but
> hides it from the application, frees the application, and
> is much easier to change than the application itself.

Again agreement. We know the future will bring changes, so we design our system accordingly.

But once again, I have to say that generally it's not the code that's the problem. Even with the best code in place and the finest patterns and most adaptable architecture. If the future maintenance and changes are put in the hands of a below average programmer (and don't forget - half of programmers are below average and always will be) then all that up front quality will be as nothing. Conversely, poor code can be rescued (refactored?) by the right people. The original quality of the code can be a help or a hinderance but it's not something that can usefully be measured and it's not the be all and end all of the final product.

Vince.

Michael

Posts: 12
Nickname: target
Registered: Jan, 2005

Re: Architecture the Accelerator Posted: Feb 24, 2005 2:32 AM
Reply to this message Reply
> There's a grave danger of falling into a meaningless
> semantic arguments. Only the programmer cares about the
> 'quality' of the code. Everyone else cares about the
> 'quality' of the product. They would say that if you have
> cut the scope of the product then you have, per se, cut
> it's quality. They would (quite rightly) rather see a
> working product with bad code than an partial product with
> perfect code.

This is always hard tradeoff. It strongly depends on client, PM and many other curcumstances, but very often customer says you that he wants all functionality on time, since he did sign the *contract* and it's *your* responsibility to ship ready product with defined functionality (note that quality is not in spec usually).

So in many projects developers work 60-80 hours/week and without weekends during 1-3 months. When scope is constant, all you have is time and quality. So overtimes and poor quality are usual in software projects.

Michael
http://www.targetprocess.com

Todd Siegel

Posts: 7
Nickname: tsiegel
Registered: Mar, 2004

Re: Architecture the Accelerator Posted: Feb 24, 2005 5:56 AM
Reply to this message Reply
Vince, I wasn't try to be bellicose, not sure why you read it that way.

> Only the programmer cares about the 'quality' of the code.
> Everyone else cares about the 'quality' of the product.

Yes, when I said 'quality' I was referring to code quality because that's where the discussion was. My assumption is that overall product quality always remains high. And programmers should care about the overall quality of the product too. That's part of being a professional programmer.

> ...if you have cut the scope of the product then you have,
> per se, cut it's quality. They would (quite rightly)
> rather see a working product with bad code than an
> partial product with perfect code.

> ...very often customer says you that he wants all
> functionality on time, since he did sign the *contract*
> and it's *your* responsibility to ship ready product with
> defined functionality.

Project "requirements" (and I put requirements in quotes to stave off a semantic discussion of the word requirement) are always changing. I view a project not in terms of it's individual requirements because those are hard to measure. I view it in terms of it's stated business goal. If the project can meet it's stated business goal within the amount of time that the customer needs it, then the team has done its job. Not every feature is part of a complete system. Some fit in to the category of "nice to haves".

I don't think I suggested delivering an incomplete or less-than-high-quality system. I've worked on teams where we removed unessential features to make the production deadline and the project was viewed as a success, being complete and of high quality. We then implemented the previously removed features in subsequent iterations (as enhancements).

Cheers,
Todd

Parag Shah

Posts: 24
Nickname: parags
Registered: Mar, 2003

Re: Architecture the Accelerator Posted: Feb 24, 2005 6:17 AM
Reply to this message Reply
> At
> some point, you will start getting diminishing returns. In
> practice, I curious to learn what people have observed
> about the actual return gained on varying levels of
> quality code.

On one of my projects I did observe diminishing returns. The client had a process which mandated that all contracts provided by classes be verified by JUnit tests, and the functionality be verified by automated functional tests using Canoo. We also had an automated build process which would run the entire suite of tests (unit and functional) after every check-in. After a point the Canoo test scripts become really unweildy because we had to test every element in the resultant JSP page with xpaths. Even a small UI modification like adding a row or changing the table layout meant struggling with Canoo for a couple of hours. The process did ensure quality of code. Manual testing at the end of each iteration yielded very few bugs. But this slowed the developement process. Not to mention the first delivery was about 3 months delayed from the original schedule of I think 18 months. However I do not know if we would have gained productivity by a more leniant build process. I am sure iteration end testing would have reported more bugs and time would have to be spent in each iteration working on them. I have a gut feel that the process of running automated functional and unit tests on every build was very good, but had the functional tests been less comprehensive, we might have gained productivity.

>Are you being
> paid to read this? Have you ever been sent by your company
> to a class or seminar, or submitted an expense report for
> a tech book? That costs money.

Excuse me for going at a tangent to the main topic. I believe these things do add a lot of value. I had suggested to a client that they do an informal architecture review of their software after every iteration. The review was to be done with a purpose of educating team members on those parts of the architecture that they were not directly involved with, and also to gain an understanding of the technologies used. If a developer had used a certain feature of Struts in that iteration which was not known to other developers then he would make a small presentation to the rest of the team. This process helped them a lot, though I am not sure how long they followed it due to time constraints. The reason I mention it here is that such processes add to code quality, but their ROI is not very clear.

> In short, no matter how you get at improving the quality
> of your codebase--whether through better processes or
> better people or both--it will cost you money.

I agree with you. Maybe the best solution is the most appropriate solution that balances time, money, quality, features, etc.
I like Darryl's phrase "fitness for purpose"

Parag

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Architecture the Accelerator Posted: Feb 24, 2005 7:44 AM
Reply to this message Reply
> Vince, I wasn't try to be bellicose, not sure why you read
> it that way.

Sorry. Actually, I was referring further back to Robert Martin's original uncompromising references to quality, earlier in this thread. It takes me several drafts to get into writing what I'm thinking and even then closing the gap between difference between the ease of saying something and the complexity of writing it still frequently eludes me.

> I don't think I suggested delivering an incomplete or
> less-than-high-quality system.

I don't think you did either. I think everyone on this thread is on the same side in that we really are trying our best to deliver the best solutions. I'd say that to do that then compromises must be made between all sorts of conflicting factors. In such circumstances any statement that opens "I will not compromise on..." (again not you) appears to be an unhelpful way of cutting down the options.

Vince.

Darryl Mataya

Posts: 9
Nickname: dmataya
Registered: Nov, 2004

Re: Architecture the Accelerator Posted: Feb 24, 2005 9:13 AM
Reply to this message Reply
> On one of my projects I did observe diminishing returns.

Parag, I am going to respectfully suggest that perhaps these returns are still positive. I concur completely that your unit test process can add what appears to be unnecessary development time. However, you may not be measuring these returns against a broader standard. The fact that it is time consuming to produce the next release provides its own benefits. In our shop for example, we try to track the velocity of changes and we note the various problems we have when we release features too quickly - the biggest one being various forms of resistance to the changes. The additional time we spend unit testing and, more importantly, working on the knowledge base and documentation updates pays huge dividends. It may be that the extra 3 months you were late saved you 3 times that in future development work. But who really knows?

This is another reason why I like a fitness for purpose orientation when making architecture, quality, and ROI decisions. If you define quality as writing and passing unit and/or system tests, you've clearly missed a point - a customer doesn't ultimately care about that.

Fitness for purpose is a quality definition that I believe only an entire organization can define - at least in for-profit ventures. It is actually quite easy to define and evaluate with metrics. For example, "completing the monthly update process in one hour or less" is one of the measurements we use in defining the quality level of our flagship product. With that definition, it is fairly objective to decide what the elements of that process are, which customers are successful or not, and which enhancements will contribute to that goal. And the same language is used in the sales process. It's not easy to get there - you still have lots of "bells and whistles" issues to deal with from both developers and marketers. But it effectively defines the landscape of the discussions.

Levi Cook

Posts: 8
Nickname: levicook
Registered: Feb, 2002

Re: Architecture the Accelerator Posted: Feb 24, 2005 9:36 AM
Reply to this message Reply
> I wouldn't say that any of us should reduce quality so
> much as be satisfied with varying degrees of quality
> depending on the circumstance. Let me give you a
> metaphor in the building architecture world.

Are you implying code quality is a linear measurement we can evaluate without considering its context?

> ... By contrast, in the lobby of that same hotel there
> was a staircase that was nicely curved and carpeted. The
> railing was wooden and polished. It was a higher quality
> set of stairs.

I don't agree--I believe context matters. Fitness for purpose, IMO, is a first order factor in measuring the quality of these stairs. If you're trying to evacuate the building, I'm fairly sure you would prefer a non-skid surface and steel safety rails over the polished rails and carpeting.

Maybe you and Uncle Bob are just working with different definitions of Quality.

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: Architecture the Accelerator Posted: Feb 24, 2005 10:04 AM
Reply to this message Reply
> I will not accept the argument that says we have to
> reduce quality to achieve time-to-market.

Sure, putting it that way you are indeed right. Nobody reduces quality in order to achieve time to market. But quality takes time and putting more quality into a product can cause missing deadlines. The question is, how much time do you spend to improve quality when a deadline approaches rapidly?

So you do not reduce quality but you compromise quality in order to just quickly make the product work. Isn't that even a principle of TDD? What else is faking some functionality just to get a green bar?

Maybe we can agree eventually on delivering quality incrementally. But that implies that quality is lower in the beginning and if you deliver periodically then you deliver with lower quality in the beginning.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Architecture the Accelerator Posted: Feb 24, 2005 12:47 PM
Reply to this message Reply
> > I wouldn't say that any of us should reduce quality so
> > much as be satisfied with varying degrees of quality
> > depending on the circumstance. Let me give you a
> > metaphor in the building architecture world.
>
> Are you implying code quality is a linear measurement we
> can evaluate without considering its context?
>
> > ... By contrast, in the lobby of that same hotel there
> > was a staircase that was nicely curved and carpeted. The
>
> > railing was wooden and polished. It was a higher
> quality
> > set of stairs.
>
> I don't agree--I believe context matters. Fitness for
> purpose, IMO, is a first order factor in measuring the
> quality of these stairs. If you're trying to evacuate the
> building, I'm fairly sure you would prefer a non-skid
> surface and steel safety rails over the polished rails and
> carpeting.
>
I agree with you about fitness for purpose, especially if you mean business purpose. Quality is subjective, so it is not something you can objectively measure on a linear scale. But you can measure cost that way. You can count how much money you've spent.

The way I map the stairs metaphor to software is via cost. The hotel is willing to spend more money building the carpeted stairs in the lobby than they concrete emergency exit stairs. The lobby stairs' business purpose includes 1) providing a commonly used way for customers to access the next floor up or down, 2) impressing or at least not repelling customers when they walk in the door. The hotel is willing to spend that extra money because they see the return on investment.

Moreover, the hotel is willing to spend more money over the lifetime of the lobby stairs to keep it clean compared the emergency stairs. I kept seeing cleaning people using the emergency stairs to move between floors, but I never saw them actually clean the stairs. The emergency exit stairs were downright filthy, because they hotel didn't see a compelling return on investment for keeping them any cleaner. The cleanliness of those stairs made little difference to the customers, because most customers never saw them. And during a real emergency, when the customers would see the filth, they wouldn't care. They only quality they would care about at that time that the stairs enabled them to get efficiently and safely out of the building.

Keeping code clean by refactoring and good test coverage costs money, just like keeping the stairs clean. And although quality is subjective, I find that the more I invest in refactoring and writing tests the higher quality code I can produce (though eventually I start getting diminishing returns). In other words, the more time/money I invest, the better factored the program gets, the more consistent the naming, the more focused the classes and methods--the better the code would score when judged on all the usual OO best-practice heuristics.

I once worked at a company that created equipment for semiconductor manufacturers, and we occasionally had to go into "clean rooms" to do testing of our software. We had to put on white outfits, booties and shower-cap like hats, because the clean room requirements were to have only one particle per thousand or million (I don't remember the exact number). The floors in those clean rooms were pretty darn clean, but it cost a lot of money to get there. The business was willing to invest that money to get that level of cleanliness because they saw a return worth the price. Compared to the clean room floor, the lobby stairs in that Chinese hotel were filthy.

I think it is more important to focus on the quality/cleanliness of class and method interfaces than implementations, and on published APIs than on internal APIs. I spent a lot more time trying to maximize the usability of the ServiceUI API, for example, than I do the internal Artima APIs. I also suspect it you get a better return when focusing on quality when establishing architectural conventions that will live a long time than when fitting things into an existing architecture, because it is easier to clean up cruft stuck in-between the struts of a solid, well-crafted architecture than fixing a badly formed architecture. In fact I have observed that this is one way a good architecture helps me move quickly: it allows me to whip something out to meet a deadline, because it keeps the system standing while the cruft is in there, and it supports me if and when I go in to spend a bit of time/money to rework that cruft into something more polished.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Architecture the Accelerator Posted: Feb 24, 2005 1:02 PM
Reply to this message Reply
"I agree with you about fitness for purpose, especially if you mean business purpose. Quality is subjective, so it is not something you can objectively measure on a linear scale."

We can't measure quality on a linear scale because it's multi-dimensional.

Why can't we "objectively measure on a linear scale" attributes which in combination form a surrogate for subjective quality?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Architecture the Accelerator Posted: Feb 24, 2005 3:02 PM
Reply to this message Reply
> "I agree with you about fitness for purpose, especially
> if you mean business purpose. Quality is subjective, so it
> is not something you can objectively measure on a linear
> scale."

>
> We can't measure quality on a linear scale because it's
> multi-dimensional.
>
> Why can't we "objectively measure on a linear scale"
> attributes which in combination form a surrogate for
> subjective quality?

A philosopher might argue that it is impossible to measure quality because it is subjective, by definition unmeasurable, but in practice there are many useful things that could be measured. My father's job for most of the latter part of his career was to go around to vendors measuring parts that were ordered by his company against certain quality criteria, and either rejecting or accepting them en masse. That kind of thing can be done for software, and in fact is done all the time.

Most software shops have an unwritten cultural rule that is unacceptable to check something in that doesn't compile. A failed compile is an indication of a quality problem. It is usually discouraged to check something in that doesn't pass all the tests, though understood if the tests take a long time to run that sometimes this will happen. But in general, a red bar indicates a quality issue. Code coverage tools are a simplistic measure of the quality of the tests. Tools that graphically show connections between packages give people feedback on coupling and layering. That is a measure of quality. Design reviews also are quality checks, allowing team members to subjectively judge the quality of another's work, and gently nudging them in higher quality directions. Similar feedback and nudging usually happens during pair programming.

But despite all that, quality is ultimately subjective. I may think a particular method name is bad that you think is just fine, and there's no right or wrong answer. But if either of us decided to rename that method to make it still better, it would take time and money.

Flat View: This topic has 59 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: I'd rather use a socket. Previous Topic   Next Topic Topic: The Price Of Two

Sponsored Links



Google
  Web Artima.com   

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