* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Importance of good software architecture

I've been thinking about this for a bit. All my apps are... Let's just say a little lacking in the "good software architecture" department. This has pros and cons.

Pros: it's very easy to get initial versions out and this has made me some good money.
Cons: it's very hard to do significant modifications which I believe is restricting growth since it is hard, if not impossible to add some necessary features.

So as time goes on, I find the cons to be a huge issue. I'm wondering what your experiences and comments are with this situation.
Bring back anon Send private email
Thursday, April 04, 2013
 
 
I think Joel covered this topic well in his "Things You Should Never Do, Part I" article (see: http://www.joelonsoftware.com/articles/fog0000000069.html ).

To sum up in a sentence: refactor your code, don't re-write it.
Wyatt O'Day Send private email
Thursday, April 04, 2013
 
 
My very scientific, carefully surveyed opinion is that 95% of the software in real-world use falls into this category.

You know what they say: there are 2 kinds of software: software that's nicely architected and coded, and software that people use.

Anyway, look at it this way, if you had done things differently, you probably would never have gotten to the "made me some good money" stage, so in that sense it's a good problem to have!
GregT Send private email
Thursday, April 04, 2013
 
 
It is also risky to spend ages carefully architecting a product that it turns out no-one wants. Also the architecture you design may not match what people want. IMHO better to get something out fairly quickly and then refactor to pay back the 'design debt' as appropriate.

See also:
http://en.wikipedia.org/wiki/Big_ball_of_mud
Andy Brice Send private email
Thursday, April 04, 2013
 
 
Damnit.
Bring back anon Send private email
Thursday, April 04, 2013
 
 
This is a perfect example of Technical Debt.

http://en.wikipedia.org/wiki/Technical_debt
Doug Send private email
Thursday, April 04, 2013
 
 
Thinking about architecture too much is a form of premature optimisation IMHO, although YMMV.
Scorpio Send private email
Friday, April 05, 2013
 
 
I didn't think about it at all when I started and now I realize that a good, basic architecture would have made so much other stuff easier.
Bring back anon Send private email
Friday, April 05, 2013
 
 
You can always migrate / refactor when the sales are coming in & paying for your time, but you can't get back the unpaid time spent architecting a product which no-one wanted.
Jonathan Matthews Send private email
Friday, April 05, 2013
 
 
^^^ note - the engineering side of my brain NEVER wants to listen to this reasoning and has to be beaten up by the business side & made to ship. My misv schizophrenia at work there.
Jonathan Matthews Send private email
Friday, April 05, 2013
 
 
+1 to Jonathan. If you are an entrepreneur running a µISV, then getting a product to market is more important than refining the architecture.
Scorpio Send private email
Friday, April 05, 2013
 
 
There is a good, there is bad and there is good enough.

I tend to do things right (design vise)  first time around which might hurt  business side but it make me feel good and it pays out in the long run.

"Bad" is not an option regardless.

IMHO of course.
Maksym Sherbinin Send private email
Friday, April 05, 2013
 
 
I've been struggling with this for the last couple of years, I have a C++ product I launched in 2002 and the code base is really showing it's age. Not only that but it relies on libraries that aren't available in 64 bit versions and were questionable to start with. Finally there are changes coming in future versions of Windows that will make a lot of the code obsolete (some of it is at device driver level).

I will probably start a rewrite this year even though I'm not 100% convinced it's the correct decision.
Ducknald Don Send private email
Friday, April 05, 2013
 
 
> Cons: it's very hard to do significant modifications which I believe
> is restricting growth since it is hard, if not impossible to add some
> necessary features.

> So as time goes on, I find the cons to be a huge issue.

I'm just curious:  what, roughly, is it about your non-optimal architecture makes it "impossible" to add some features?

I tried to change an application (in place, not rewriting from scratch) to use the MVC pattern once and gave up after two frustrating weeks of flopping.  In the end, as long as long as I don't want to port the code to be web-based, it probably won't matter.

My own struggles with technical debt are not so much architectural (I don't think) as much as just bad practices here and there--due to previously having less experience when I wrote them--that occasionally are revealed to cause quasi-critical problems.
Racky Send private email
Friday, April 05, 2013
 
 
>>I'm just curious:  what, roughly, is it about your non-optimal architecture makes it "impossible" to add some features?

My 2c is inadequate attention paid to encapsulation.
Drummer Send private email
Friday, April 05, 2013
 
 
I think the most important thing you can do is find repetitive code and refactor it. Refactoring probably provides 80% of the results.
cn Send private email
Friday, April 05, 2013
 
 
I work my ass off to have a good architecture, to fight bit rot, and to refactor things before adding new features.

Even will all this it's constantly a huge ball of mud and major complexity problem.

If you don't fight it, you're probably especially screwed.

As time goes by the counter measures become more and more elaborate.

For example, once you get above 100,000 lines of code, you really need to be thinking of implementing most everything in a domain specific language, which your application is the interpreter for.
Scott Send private email
Saturday, April 06, 2013
 
 
Be wary of thinking you can go back and rewrite an application later.  In my 30 years of experience that rarely happens.  Once money starts coming in, the company begins to grow.  At that point you will never feel like you have time or resources to rewrite a large product.  As they say, if you don't have time to do something right what makes you think you will have the time to do it over?
David Hancock Send private email
Saturday, April 06, 2013
 
 
It is always in my dream to create my software with a good design and easy to modify in the future. Several times i am thinking to redesign my software from scratches but it never happen. I kept always do the same think again when adding a new feature and get use to it.

Sure it got me some time to understand my own spaghetti code when adding a new feature. but over the long period it seemed that my small modification in here and there becoming better and better without having to create from scratches. Thus this save some time and generate more revenue when releasing new version faster.

However, i recorded all my mistake and i try not to do that again in my next software adventures.

Note: i am not someone that hold an IT degree, only learn software for hobby in the first place.
Fherry Send private email
Saturday, April 06, 2013
 
 
@Fherry
Native english speakers say 'from scratch' but I quite your 'from scratches'! :)
Drummer Send private email
Saturday, April 06, 2013
 
 
Duh...should have wrote 'I quite like'
Drummer Send private email
Saturday, April 06, 2013
 
 
haha..........i'm not native English. sorry :)
Fherry Send private email
Sunday, April 07, 2013
 
 
Scott, I think you and I align ideologically so I guess I need to leave this shithole called the land of the free AND be more stringent about software architecture ;)

I made this post because I was unsure of which I should go but reading the answers helped me make the decision to continue to with aiming for an excellent architecture. It's already showing huge returns in productivity as well as the ability to solve problems I could not previously. Now to make sure that I don't spend too much time with intellectual masturbation and get it out there.
Bring back anon Send private email
Sunday, April 07, 2013
 
 
>> intellectual masturbation

Ah, yes, the distant and far more unsightly cousin to "Technical Debt".  Now we just need a Wikipedia entry to articulate this concept fully. ha.
BI Baracus Send private email
Sunday, April 07, 2013
 
 
The term you're looking for is architecture astronaut. Did Joel really coin it? Our host is certainly a smart cookie. http://www.joelonsoftware.com/articles/fog0000000018.html
Bring back anon Send private email
Sunday, April 07, 2013
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz