Fog Creek Software
Discussion Board




The Real Problem

The real problem with software is that it is always one person or a group of people trying to solve other peoples problems or trying to predict other peoples needs and create solutions. 

It is only when -anyone- can create their own software - to solve their own specific needs - at a given point in time - in a minimal amount of time - that the software problem will be solved.  Maybe not even then...

The problem is that communication is not universal.  Your ideas and thoughts on a topic are not mine just as mine ideas and thoughts on the same topic are not yours.  There is no piece of software that can transition the two.  Or is there?

Xylaphone
Thursday, March 13, 2003

"...that the software problem will be solved...."

What problem?

anon
Thursday, March 13, 2003

I would say the 2 real problems are the difficulty of estimating how long a project will take, and the tendency of clients to keep changing the goals of the project.

I also have a pet theory that the price of packaged software has lead people to erroneously believe that custom software development costs too much.

Matthew Lock
Thursday, March 13, 2003

The two problems are related.  Probably the biggest source of uncertainty that is under the control of the customer is project scope.  If you can manage the scope, most of the time the other problem goes away, or at least becomes manageable.  Tell 'em if they want precise estimates, then give you precise requirements.

anon
Friday, March 14, 2003

Maybe the best first post I've seen in years.

Yeah, you've got it.

Ever wonder why so many vertical market apps (like vet offices, dry cleaning, etc) are such pieces of shit?

Because the guys who wrote the code were vets or dry cleaners first, and software developers second.  Best case, probably had their brother-in-law "just out of the joint" do it.  Why?  Because THEY UNDERSTOOD THEIR BUSINESS, and wished to merely use software to do something useful like make more money with less manual work.  What a concept.

How many dry cleaners really understand software development?

How many software developers really understand the business model of dry cleaning?

The $64K question is how many dry cleaners developing their own vertical market app are willing to pay for professionals to develop it for them?

Answer = almost zero.  "Hey, our app runs fine as long as you rebuild when it says "record is not found!"".

Now you get it ...

Mitch & Murray (from downtown)
Friday, March 14, 2003

According to the Theory of Constraints (TOC) - there generally exists only a couple of Core problems - looks like that is what you (Xylaphone) are addressing.

Prakash S
Friday, March 14, 2003

Matthew, you are absolutely right. But then those people do not know the first things about basic economics.


Friday, March 14, 2003

Remember that specialisation is not unqiue to programming.  Whenever we need something donet that requires a high level of skill we need to call in the professionals:  Law, plumbing, building, etc, etc.

As professionals what we need to do is learn how to listen to those we serve.

Ged Byrne
Friday, March 14, 2003

I think most software is fundamentally designed to improve an established process of some kind.  If the process is flawed the software will be flawed and a good process will usually result in software that will meet at least 90% if not all of a clients needs. 

Most complaints about bug free but unsatisfactory software are the " it doesn't do what I want it to do " kind.

Hence if a process is very well defined early on within a project and any flaws, bottlenecks, mismatches etc can be exposed and corrected, development can occur in a more timely and efficiently.

However as a rule humans (including me would you believe it) tend to lapse and are not always able to thoroughly analyse or define their personal or company processes.  We always seem to miss something be it detailed, trivial, obvious whatever.

Maybe The Real Problem's only true answer is to ask God to make us more meticulous and detailed. 

Yes!  God should make us all Vulcans but without the cold, logical personality and somewhat obvious inability to have loving relationships and good sex.

Tech Chimp 03
Friday, March 14, 2003

Xylaphone, I am going to play devil's advocate for a little bit.

One package that immediately springs to mind, is MS Access. If you access me, the lack of a db that easy to use is what is holding back migration to suites like OpenOffice.

People around the world use it to help them work better. Each access database with forms is a basic application, and for the most part, does the job well.

The problem is that a lot of software developers view these custom apps as vile, and not professional, and advocate for the removal of access from users desktops.  http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=28465&ixReplies=26

The point they miss is that apps like this actually do the job. A user might have 20 databases that they use alone, or share with their team. To a developer, that is wrong. Why not hold the info centrally? Why not nomalize the databases better? Why not standardise the fonts?

Like I said in an earlier thread, I was tempted at one point at work do create a 'better' solution to the tens of databases we use in our team of about 20. Having watched how the users used them though, I decided against it. If I built it, it might be better from an engineering perspective, but from a users' it would be hell.  They are always changing things in their databases. Adding a field here and there. Creating a new report or query etc etc. All I can do is help when they are trying to do something.

To expect them to learn SQL, or to produce data models normalised to the 5th form is silly.

In short, maybe developers should stop looking at software as a way to solve interesting technical problems, but as a tool to allow users to create the software that they use in their day to day jobs, with everchanging requirements.

tapiwa
Friday, March 14, 2003

tapiwa, I think hits on a key point, one that I've been formulating in my head for some time now... I think many technical folks get so enamored with the technology or finding the perfect solution to solving 'technical' problems that they lose sight of the the real 'business' problems that they are trying to solve.

A prime example of this is the OO programmer who spends so much time generating the 'perfect' object model that in his/her mind is going to solve the worlds problems. In the mean time the software gets scrapped because it doesn't meet the business' needs and never gets used because other programmers find it too massive and unwieldy.

Carl
Friday, March 14, 2003

"The real problem with cars is that it is always one person or a group of people trying to solve other peoples problems or trying to predict other peoples needs and create solutions. 

It is only when -anyone- can create their own car - to solve their own specific needs - at a given point in time - in a minimal amount of time - that the car problem will be solved.  Maybe not even then..."

You can substitute almost anything here. We've had specialization since the middle ages - or even earlier. Software is no different.

igor
Friday, March 14, 2003

Maybe one day programming talents of sorts, will be equivalent to writing today.

The computer = paper and paper. Software= Writing. Give someone a blank piece of paper and a pen, and they can generally put their ideas down, and communicate.

On the other hand, someone with a thorough understanding of the business process might not have the ability to translate those thoughts, not into code, but into a business supporting tool.

Before you dismiss the analogy, remember that until a few hundred years ago, reading and writing were the preserve of priests and kings. Folk did not read the newspaper... they listened to the Town Crier.

Today, you still have professional writers, copy writers etc, but Joe Average does not need to employ someone to write a letter for him.

A bit like the Cathedral and the Bazaar. I am don't think that it will happen any time soon, but one day I think the 'writing' tools will be easy enough to be available to all, and the people will have learnt to 'write' from an early age, as part of standard learning.

tapiwa
Friday, March 14, 2003

I agree with the problem, but not with the proposed solution.

I would say, it is only when -anyone- can truly drive the creation of their own software - to solve their own specific needs - at a given point in time - in a minimal amount of time - that the software problem will be solved.  Maybe not even then.

I don't wish to harp on Extreme Programming, but that's one of the problems that XP purports to solve.  The customer is on-site, s/he specifies all the functionality directly to the developers, and iterations are short enough that the customer can quickly see changes and order new functionality.

Brent P. Newhall
Friday, March 14, 2003

I'm not convinced that most vertical apps are  'pieces of feces' :-)

Most vertical apps are ugly but highly functional. They service their users' needs. That, why people use them.

Software developers are no exception to this rule: look at Emacs, Linux, and Perl for examples of ugly but functional 'vertical market' software embraced by programmers.

In my experience, most software projects waste way too much time and energy making the software 'user friendly' and 'scalable' and 'object oriented' and too little time making it deliver functionality in a robust and error free way.

(not trying to troll, not intended to attack anyone!)

--
http://www.braithwaite-lee.com

Reginald Braithwaite-Lee
Friday, March 14, 2003

One opposite point - most software indeed is a kind of 'automator' of current established tasks. But there is also the software that creates a new model, and opens a door for users too. Visicalc would be an obvious example. Partly software isn't always personalized enough, but more often it isn't inspiring enough - it doesn't make the user say ah-ha!

If one program simplifies a step, and another makes it irrelevant, I'll vote on program 2. Great software, in a weird way, is all about destroying value.

Robin Debreuil
Friday, March 14, 2003

There's a circularity in the argument that started this thread.

I think the fact is that perceiving the relationships and requirements of a software need is quite difficult, and few people can do it well. A good software engineer is precisely that person who can do it well.

Writing is the same, by the way. Many people can write things, but some are much capture at accurately capturing meaning and intent.

Must be a manager
Friday, March 14, 2003

Whoops. Writing is the same, by the way. Many people can write things, but some are much _better_ at accurately capturing meaning and intent.

Must be a manager
Friday, March 14, 2003

I've read in various places that Adobe is one of the "we know much better than the luser" companies. It can get away with an atrocious interface firstly because of the other things it does better than anybody else, and secondly because so many people have been forced to use it that it has become the norm, so even programs such as Corel's Photo Paint copy the basic design.

The best user interface I've seen was MS Photodraw, but because it was different from the Photoshop way of doing things it never took off (being buggy didn't help either - it was the source of my favourite MSKB bug, "MS Photo Draw won't start if an odd number of fonts are installed on the machine".

Now from what I've heard Photoshop is positively user-friendly compared to Quark Express.

Stephen Jones
Saturday, March 15, 2003

What does that have to do with "The Real Problem"?

A_Troll_001
Saturday, March 15, 2003

Dear A troll,
                  Nothing. It was meant to be a reply to another message. I don't know if it was my fault, or if it was a bug in the software that sent me to the wrong link for the reply. I have seen this problem arise half a dozen times or so in the last week. Hopefully all three messages will be deleted.

Steve

Stephen Jones
Saturday, March 15, 2003

I think it boils down to a mentality problem.  We do what we do to make money to survive in the world.  In order to make money, the business man needs a certain problem solved.  He would think: "how can I solve it while keeping costs down". 

He hires an engineer and that is already a level of indirection.  If he has to go through a team, that's two or three levels of indirection.

The engineer/programmer is more concerned about his product's structure.    He is far enough removed from the customer that chances of what he produces will satisfy the customer is a little low.

If he were his own customer, it will be another matter.  Just notice how much you change your initial requirements if you were to write a program for yourself.  More than 90% of the time, it has morphed away from the initial plans.

Hoang Do
Saturday, March 15, 2003

"Like I said in an earlier thread, I was tempted at one point at work do create a 'better' solution to the tens of databases we use in our team of about 20. Having watched how the users used them though, I decided against it. If I built it, it might be better from an engineering perspective, but from a users' it would be hell.  They are always changing things in their databases. Adding a field here and there. Creating a new report or query etc etc. All I can do is help when they are trying to do something."

This is a very good point. Small db's are like pieces of paper on your desk, while central db's are like libraries. Both have their place. It might become really silly when librarians (db guys) start to dictate how the papers should reside on the local desks, and how they should be accessed.

I have seen some db guys so fixated on the idea of storing everything in a central db that the info becomes a lot less usable to those currently actively using it.

If a central db does not fit user needs, it should not become an end by itself.

This was a good essay on paper use which has good parallels with local vs. central storage and usage arguments. Here is the link:
http://www.gladwell.com/2002/2002_03_25_a_paper.htm

LazyCat
Saturday, March 15, 2003

I think its already true that people write software to fulfill their own needs -- when they are motivated to do so.

Example: VST software synthesizers. Steinberg created a decent C++ plugin API for softsynthesizers. Now tens of thousands of people, most of whom have no previous experience programming, are writing DSP code in C++, learning about convolution, comparing the performance of various FFT algorithms, learning about imaginary numbers, complex math, pole-zero diagrams, Chebychev polynomials, obscure FP errors in various processors and how to get around them, synchronizing multiple processors at the interrupt level with their own handmade PPC assembly, etc etc. All pretty advanced stuff. Most of them are musicians with little or no prior programming experience. They do it because it enables them to make cool things. The complexity of the math, the difficulties of the problems, the subtleties of awesome UI design, these are all things that an average guy with a high school education and a few years experience playing in a band master if he is motivated.

X. J. Scott
Sunday, March 16, 2003

*  Recent Topics

*  Fog Creek Home