The Problem with Design and Implementation
Linked by Yamin on Wed 9th Sep 2009 16:17 UTC
General Development I've been developing software for quite a few years. One of the issues that seems to come up again and again in my work is this concept of design and implementation. I recall it being a significant part of my education at the University of Waterloo's Computer Engineering program as well. The message was always the same. Never write code first. First you must design software by writing a design document, flow charts, pseudo-code, timing charts... then it's merely a trivial matter of implementing it. Make note of the attitude here given towards implementing. The real work is in the design, and it's just a trivial matter of implementing it. It sounds so simple doesn't it? Now, how often does this work out in real life?
E-mail Print r 8   · Read More · 82 Comment(s) http://osne.ws/h2v
Thread beginning with comment 383684
To view parent comment, click here.
To read all comments associated with this story, please click here.
TemporalBeing
Member since:
2007-08-22

To some degree, a very well agree with you, and you simply misunderstand by what I mean by discipline.

To start with, as with any other job, the only people that really going to be good at the job are those that truly love it and are dedicated to it - this holds true whether you are a shop keeper, a welder, a CEO, a programmer, or even (dare I say) a politician. On that point we agree.

However, you don't see the discipline in which I speak - you mis-associate so what you are thinking is different from I am thinking. So please bear with me while I layout my thoughts, and try to make them as clear as possible at the moment - at least those which I have thought enough to be able to well formulate.

So let us first layout what I mean by discipline:

To start with, a programmer must exercise great discipline in how a program is laid out. Logic should be clear, predictable, well documented (e.g. comments in the code that are clear). Coding style should be uniform across the team and the company as a whole; that is not to say that the programmers would not work to build a single coding style, but once laid the MUST follow it, leaving their arrogance aside. (A hard task, but it is a must if software programmers are to be respected.) Errors must be handled - ALL errors, not just those that are expected.

While there is more I can say, I have more thought to do before saying it aside from what else I will answer while responding to your comments below.

Give the programmers more freedom; give them more responsibility. Throw out the ideas of requirement gathering and design as separate and disconnected phases and give the programmers-- the ones actually implementing the code-- a direct, open dialogue with the clients. Allow programmers to do what they love to do: solve problems.


I very much agree that programmers need more freedom; but not likely on what that freedom is. For instance, coding style is not a freedom for the programmer - to a company, programmers come and go; but the programs remain, and another programmer must be able to pick up the work and continue it on. Programmers need to realize that they are not the only person to work on a project and that they must build the project such that the next fellow can pick it up - the only assumptions should be that they will be familiar with the field in which the program is targeted; that is - if the program is specific to a field of biology, the comments should reflect that and speak to that field so that a programmer (who may not be quite as experienced as the one writing the code) may be able to pick up the software and continue. Likewise, the programming style should be uniform so that any programmer working at the company can quickly pick up the program's source and be able to understand it - having similar logic, error handling, etc; allowances of course as implementation languages dictate.

However, I very much agree that the programmers - the technical people - need to be involved in the requirements gathering and design - e.g. the concept of operations, analysis, architecture, requirements, architecture, etc. The earlier they are involved the better - and not just one programming individual, the whole team in so far as who is working on the project. (E.g. if developer A is not assigned to the project, then they should not be in the meetings; but once it is realized that developer A will be on the project they should be immediately brought in, brought up to speed, and made part of the effort from then on.)

Let them talk to the customer - or at minimum, let them listen in directly on the conversation - e.g. they're in the same room during the discussion - even if the company wants all questions to go through a specific individual who ultimately talks to the customer; and give them some way to pass questions to that individual on the fly.

I realize that most on this list will not like many aspects of the discipline I propose - and for that, I simply would have to reply - grow up, humble yourself, and learn to work as a team for the company. Creativity can still be had within those limits, and far more will be doable and achievable. And if I were your boss and you wouldn't follow the policies set forth, you'd be out on the street just like anyone else who wouldn't follow the company policies - following such policies is part of your employment contract. (And yes, it is legal to let someone go on those grounds.) The sooner you realize that businesses are less and less going to let programmers get away with the antics they have in the past, the better - because it is changing.

Instead of thinking that your job security lay in that only you can understand the code (it doesn't - it never will), think instead of your job security as the ability for you to bring profit to the company - the more you can bring, the better. (And yes, that can be with FOSS too!) But it first starts with working to achieve standard processes, policies, etc. for writing software and then following them and ensuring the whole team follows them.

And if you don't think this works - just look at the Linux Kernel. No patch is accepted unless it meets the standards set forth by Linus and his band of lieutenants - standards that even layout an explicit coding style. It works; and it can be achieved even among the most creative.

There is a time for being creative, artistic and there is a time for it not. Learning to differentiate between them is a good software engineers responsibility; and doing so shows a great maturity that will garnish respect. Coding style is one of those times to set aside your creativity and artistry and just get with it; your work life will be better for it too.

And, btw, I do my best to do this myself. I have one preferred coding style; but I do my best to follow what has been set before me. I may use my own style on projects (it does fit the guidelines of my company - the company coding style is too inclusive to start with, but that's all I shall say on that), but I also try to fit code for others projects in the same coding style that project uses. In other words - I try to adapt to what the company requires of me, no matter my genius or lack thereof.

Reply Parent Score: 2

cb_osn Member since:
2006-02-26

However, you don't see the discipline in which I speak - you mis-associate so what you are thinking is different from I am thinking. So please bear with me while I layout my thoughts, and try to make them as clear as possible at the moment - at least those which I have thought enough to be able to well formulate.

So let us first layout what I mean by discipline: [...]

From your description of what you intended by discipline, I don't disagree at all. In fact, I was also going to point out a few open source projects that fare well in the code quality department-- one was the Linux kernel, as you mentioned, and another is Webkit. Both projects have strict requirements for style and organization when it comes to accepting code. But my reason for choosing open source projects was to show that better quality code can be achieved when programmers are able to take the reins.

I'll probably stumble a bit here too while I present my thoughts because I think the points where we disagree may be subtle.

I suppose my point of contention is regarding the solution to the problem. I firmly believe that modern software engineering practices encourage shoddy code by embracing the bad programmers and stifling the good ones. I'm sure there are others like you who are able to maintain their integrity and produce quality code under those circumstances. I readily admit that I am not one of them. Put in a situation where I am handed a design document and told to implement it, I would slop out whatever code is necessary to make it work and then go home. And I'm a person who is positively anal about properly structured code, strict style guidelines, and helpful comments. Luckily (for me and for those who may have the fortune to work on some of my older code), before venturing out on my own to do the indie game stuff, I worked in the game industry where those types of design methodologies aren't typically used and programmers have control over the process because those sitting up above simply don't have the necessary knowledge to produce a specification of any worth whatsoever.

Now, I don't intend to shift the responsibility for bad code away from the programmers that produce it. They certainly hold the blame. My assertion is that bad code is the expected result of current software engineering practices, regardless of where the blame may lie. We can't change the culture without changing the environment. As long as the methods stay the same, the outcome won't be any different.

Reply Parent Score: 2

TemporalBeing Member since:
2007-08-22

Well, I had written alot more, and then lost it.

But basically:

I think we agree very much.

As with other engineering disciplines, when the Software truly becomes a discipline, the geniuses will be able to excel while the standards will keep the slackers either from the field entirely or at the very least, from doing too much damage.

I find Traditional Software Engineering, and "modern" software engineering to be wholly insufficient and utter failures at the task - but again, I think this is partly to blame because of the lack of true discipline in the field. Software Engineering only works when there is a basic level of common understanding on how to do things - a common language that all understand, a common methodology for how things work, and a common level of competence such that failures and successes can be learned from.

In other words, the software field is presently very chaotic with everyone wanting to do their own thing. Some work out, but sheer luck; while most fail. In developing standard practices, and a true discipline to the field - one that is taught as rigorously as any other engineering field is - then we should be able to turn the tide, and instead of the majority of software projects failing (as is today), we can have the majority succeeding.

When the software field is disciplined as such, THEN we can certify software engineers much like we do any other engineering field. Where as today, we have one U.S. State (Texas) that does so, and part of is simply testing ones knowledge of UML - something which most use, and is truly useless to the software field. A certification of engineering is only useful when it can test standard practices, but the standard practices must first exist, and today they do not. Hopefully, by the end of my career they will - I at least certainly aim to my part to ensuring they do by then.

I suppose my point of contention is regarding the solution to the problem. I firmly believe that modern software engineering practices encourage shoddy code by embracing the bad programmers and stifling the good ones.


As Software Engineering is presently defined, I agree. However, I think it is defined incorrectly, and a proper definition will bring out the best, especially in the good ones who would be able to excel even more.

And if you think I am wrong, consider how well other engineering fields still maintain their superstars - how people shine in those fields, and how respected they are. Now contrast that today, with how the "best" of software are seldom respected, and mostly found to be arrogant - there are exceptions, but they are few.

Managers typically hate software developers, because they find them unmanageable; and that is primarily because of the lack of discipline in the field which directly leads to a lack of control of the projects. Time estimations are presently worthless, but with proper discipline can actually be done with little error - and that is what management wants, and what helps make a profits for the company.

Such discipline would also benefit both open source and commercial software projects. Not just one or the other.

Reply Parent Score: 2

Read more of this thread... >