Can programming be separated from software design?

[petey]

This question has a lot of implications for the viability of outsourcing/offshoring. In software development, can code writing be separated from software design? Outsourcing is a good example because it basically lops the process in two: design by business teams on-shore, code-writing by programmers offshore. Does this type of thing hurt the software development process, or does a clean line of separation already exist? For example in my case, I get the business requirements after several high-level discussion take place. Inevitably the requirements have to be interpreted and the holes filled in, which requires direct interaction between the dev team and its customers. Disrupting this communication would hurt our project.

Another variable in the mix is new-age development methodologies that try to acheive the separation by treating code-writing as a distinct bullet on the deliverable chart. My dept. subscribes to such a methodology and we always deliver on-time and under-budget, but truth be told there is little correlation between our PM's charts and what we actually do as programmers over the course of the deliverable. The methodology ends up being a feel-good process for management to wave before execs. Other bigger projects in my dept. that stick closer to the plan constantly flounder because the business teams can't seem to get their requirements across, trumping any chance for the methodology to be of any use in the first place.

Overall, I think trying to separate programming and design is likely a bad (or fatal) move, but that's based on my individual experience. Thoughts?

http://www.drpeterjones.com/

News and views of some obscure guy

 

[dilettante]

I think such a separation only works when you are building something that falls along the lines of some well-known paradigm and is built using well-worn technologies everyone involved is very familiar with. On the order of building yet another report program in RPG or Cobol, yet another simple ASP form-based data gathering or inquiry application, etc.

That way a PM can get reasonable estimates for the ever-popular project plan, and an appropriate set of boxes and lines from people so they can "design" the application.

Whenever a group is breaking ground with new tools or venturing into a new application realm though... project plans and Visio diagrams may represent fiction more than reality. You end up with a number of fits and starts, backtracking and retrenching or else end up delivering something with a set of nasty issues such as operational, performance, reliability, and maintainability problems.

Heaven help the team who's PM is drunk on the voodoo of CASE tools and UML. Then throw in "professional testers" who were working the customer counter in a branch office last week... well, it sure can be fun!

Gathering the requirements for a project can be pretty dicey. Sometimes it is handled well, other times not so well. Lately I'm seeing something analogous to a contractor who sends out a stooge with no practical experience to find out what a customer needs in a new heating and cooling system. Said stooge knows nothing about heating and cooling, and is really just an order-taker working out of a catalog. The customer runs an accounting business and knows maybe a hair more about heating and cooling, and maybe a bit about her building. You can imagine having a crew come in and work off the resulting plan with whatever pieces and parts the stooge ordered. Then the nephew with a sociology degree comes in to balance and fine tune the new system... but he'll learn a lot on the job! ;-)

Why do we think software development is so much more trivial than configuring and installing heating and cooling systems?

 

[RiverGuy]

Well, in most of my Systmes Analysis and Design classes in college, they seemd to subscribe to such a theory. A team would design the product. I believe another team would review it. Then they would send it off to be "programmed."

Obviously, this doesn't apply unless the organization is large enough to staff all of those people. I have no idea how prevalent it is in the real world.

Personally, I would think having two people both design and program would be more ideal that one designing and the other programming.

 

[rosieb]

Nice theory.

In every software project I've ever worked on (always in small organisations, big ones may be different), it has proved impossible to get a full specification from the users. It is not until they see a prototype, that many of the real requirements emerge.

I've always found that the most sucessful development projects came from a close on-going relationship between users, designers and coders - with a (semi-technical, but data-knowledgable) co-ordinator to liaise between the users and the designer(s), but with access to the coders.

The problem with this is that it requires a co-operative matrix management approach, often not appreciated by the managers involved - there is no clear target to blame if things go wrong. It also is highly dependant on getting the right people in place, not easy.

Rosie
"Never express yourself more clearly than you think" (Niels Bohr)

 

[harebrain]

Check out thread656-665733 here. It's 7 or 8 months old, but it gets around to this question.

 

[Loktar]

we always deliver on-time and under-budget

My jaw dropped when I read this... I thought this only happened in fairy tales and myths.

As I'm fairly new to 'real-world' programming projects having just graduated from college, I'm not that experienced with the different methodologies of software development, although I have learned enough to agree with those of you that said communication is key. From what I've seen, as long as there is a solid line of communication, projects will be infinetely more successful.

All that said, I want to say thanks to all the pro's here who have shared their experiences. I feel like I have a much better idea of what goes on out there and hopefully I'll avoid a few pitfalls along the way.

 

[bbarr]

Since I have a sarcastic sense of humor, I guess I should answer the question by saying, yes it can be separated. Of course, whether or not the results end up the way one would like them to be is a different question.

I used to plan, the plans looked nice. Nice diagrams in Visio. They look nice tacked to the side of my cubicle. I have an out-of-date data schema on my cubicle ... I don't think it is very useful anymore, except to scare people into thinking that what I do is difficult.

But then again, if I change my definition of "dificult" ...

 

[lionelhill]

Surely there is a certain psychological value in trying to separate the nitty-gritty programming from the overall design, even in a small thing where the two are tackled by the same person?

Whatever you write, a database, a game, embedded software for an electronic soup spoon, the user doesn't care tuppence HOW you implemented it, they just care what the result is. They care about the overall software design. It's not a good idea to let the programming details start to interfere with what the software is specified to do. The underlying structure of a database shouldn't be allowed to dictate what the user can do with the database; rather it should be the other way round. It's important to avoid the temptation to design the product a certain way because it's easy to implement!

Separation of programming from software design is exactly the point of black-boxes in high-level languages. It's just another level of the same idea of abstraction.

 

[Dimandja]

There is a difference between business specifications and technical specifications.

An analyst transforms business specifications into technical specifications.

The programmer uses technical specifications to code from.

Dimandja

 

[MasterRacker]

Loktar, It's easy to come in on-time if you use an ancient rule of engineering estimation:

1. Make your best guestimate of time.
2. Add 1.
3. Change to the next highest unit.

Example: If you think it will take 3 weeks - allow 4 months on the timeline...

[LOL]


Jeff
The future is already here - it's just not widely distributed yet...

 

[dilettante]

I agree with you in theory Dimandja. However my own experience tends to indicate that processes and results such as Tire Swing are much more common than theory would lead us to expect.

 

[BNPMike]

The main problem is there are many platforms nowadays that are as quick to actually implement a working system as it it would take to write a design specification. Some people, believe it or not, still write business systems in Cobo/CICS/VSAM. For them a design might be a sensible prior step to programming. For the rest of us, prototyping is altogether quicker.

Also, many solutions now involve a package of some sort whether it be Oracle CRM or Microsoft Access. In this case using the features of the package lead to massively more cost-effective systems that starting from an abstract statement of required functionality and trying to map that onto the package.

 

[robbieguy2003]

As i have only worked as an assistant programmer on Web Based management systems (server control panels for *nix enviroment, Content Management Systems) my experience tends to get the basic requirements together.

Stay the hell away from a computer, get data flow diagrams, think and pan out how the system will work and if possible spend a few days with the users seeing how they do things.

I know it might seems costly to sit down and not get anything done but from a decent system plan and overview you can figure out what modules your going to need to write and what kind of data structure your going to use which only saves time later.

Before i touch a keyboard (unless its quick bits and bobs) i want a whole system on paper that works then coding can go smoother as your concentrating on that. Not how the system will tie together.

Hope my above bumble makes some sense

User: My computers smoking.
Support: Turn it off.
User: Will i lose my work??
Support: Turn it off.

 

[smythe]

I completely agree with rosieb, in a perfect world you theoretically can do this (college course) but in the real world...

Designs specifications change, management changes their minds, and communication is often tangled... depending on the company, it's current financial status, and a host of other variables. This was very pronounced in the last small company I worked for, and still exists in the larger company I work for now, even if it is on a lesser scale. However, in my experience management of software design and the actually programming often become very closely knit as much as we don't want to admit it, we would probably like to think we can toss some specs at some guys and have them program them perfectly, but it's more like this:

You design something
Someone programs what you what
The designers realize that what they wanted isn't possible or something changed, went wrong...
The programmers make some modifications
etc...

Perhaps in very large corps where a product has been stable and around for many years and the design process is down pat this can work, but for smaller companies it is much more difficult.

 

[wmichael]

Based on recent experience with designing software for an off-shore team, I would have to state (perhaps reiterating what others have said in this thread) is that it technically *is* possible, and can occasionally work.

The company that decides to spec out what is to be coded offshore must be certain their organization is engineered to do so. Having sharp business analysts who can produce the following documentation is just a start:

- Excellent use cases. How will the suer interract with the software, and how do the system responses need to be set up. Minutiae is important here
- Helpful things like wireframes where UI is involved, and excellent process flows where backend stuff is taking place.
- Overall architecture diagrams, and other artifacts that lend to a complete overview of the entire system so that the offshore PMs can make a modicum of small decisions.

Keep in mind that when sending something offshore, people are generally paying for factory-style coding and not for creative thinking. I have not seen model that totally eliminates the need for creative thinking -- anything not specified will, at best, not get done until the specs are written in full.

Given the above, I have asked if offshore coding is really worth it. The dollars spent on taking business people away from conducting business, hiring high-end BA's to replace portions of sharp and dedicated software engineers, and all the back-and-forth to resolve an issue that may have been taken care of with a 10 minute cube visit just seem to be silly sometimes.

The idea of offshore development is still immature, and I expect the model will get much better very quickly, or that entire project teams will be sent overseas with only a skeleton crew of decision-makers in the states to talk to the clients.



~wmichael

"small change can often be found under seat cushions

 

[Dimandja]

The biggest problem in off-shoring is that many companies that "hurt" try the off-shoring "magic bullet" - "in order to fix their problems".

If you can't manage it home, you will not be able to manage it away - simple as that.

Let's face it, IT types do not skilled managers make - at least most of the time.

Off-shoring is for carefully skilled managers - which many IT firms are struggling to achieve.

After a few more off-shoring mishaps, we'll learn, I guess. When all the stupid bashing ends, we'll probably sit down and sort out the real problems.

I mean, there are companies out there who out-source, and literally "sit back and watch problems mount" - these companies couldn't swing it at home either.

Dimandja