How do you do yours ?

Morpheus

Ok picture the scene.... You walk into work on monday morning, your boss hands you a new project.

Youve to design a new (fit .NET, ASP, VB, C++, C#, JAVA, WHATEVER) GUI front end to a database (already existing).

He shows you what information he expects to be displayed,

Your starting with a main screen showing a list of project keys (from the a project table). you select a project.....

and the next screen loads. On it you can view all the data (again stored as lists of line entry records) related to that chosen project. you choose line item(s)....

and a report is generated for the data you chose.

Most of us working in the industry (maybe even in college) have done this kind of thing, nice gui, database connection, maybe a few SQL statements (depending on the backend, etc) BUT.....

HOW do you go about it from inception to conclusion... have you a method you use on every project, tailoring it depending on the size of the project?

What tools do you use???

Is it like a well oiled machine, a finely executed surgical miitary strike (with no collateral damage for those from humanities who may be reading this )...

Do you write notes on a notepad, paper, etc, do you create your own change management documents, lists of requriements, do you follow strictly software engineering steps, personal software processes, usability tests, code reviews, a combination fo some or all of these, or other methods? etc do tell...

Or indeed is your coding reminiscent of carpet-bombing from 50,000 ft, through dense cloud in a B52, with no radar, hoping in vain that the sheer amount of lines of code just might hold the application together in one usable program??

Do you simply slap everything together and test at the end, hoping it works. (im sure this has led to many a late night for most of us (me anyways!) before we learned our lesson, but can surprisingly work sometimes!!)

For me tho, my current job requires fast paced coding, punchy turn around times and ive had everything from the
"heres a feature i need" to the "wow thats great"
to the dreaded
"You mean you really cannot add the feature due to the effect it has on the already underlying coding? why cant we do that, i thought your coding was great?":dunno:

Luckily ive developed my own method of software production, based loosely on some stuff I did in college, analysis and design methodolgies, a bit of my own version of UML usually referred to around 3 weeks later as WTFML!! constantly updating a Word document detailing each change to forms, code, SQL, database, properties, scripts, etc...

So tell us all how you do the above? whats the best tools, websites you find helpful for software design.

If you have your own methods, share them, so that one day we will all be better coders.

Thankyou

Regards etc.:cool:

fractal

I have a lovely genetic algorithm (called bob) that writes most of my code for me..

Starts off by generating random binary strings eg:
1101100000101001011001

And then goes through sequences of modifying them eg:
1001100000101001011001
0101100000101001011001
1101100000101001011000 etc etc..

until eventually by pure dumb luck it has evolved into the program and equivalent set of docs that I want..

Works well now.. But twas a bit of a bitch persuading the boss we needed a little more than your pentium class hardware to run it.. Heres what we eventually used:
http://www.top500.org/lists/2003/11/1/

Works well for our sleepy little companys needs..

Earthhorse

Hmmm, not too sure. You seem to be talking exclusively about designing front ends for running reports off databases. I don't have huge experience of that but in any program I've written (which is only a few) I'm all for eating your own dog food. Use it as a user would. Does it accomplish what they want? Does it do so instinctively with no annoying or unnecessary input?

There's a great story about the current mayor of New York (Michael Bloomberg I think) coming into work one day and spotting an unacceptable amount of customers waiting in the lobby. He went over to the receptionist and asked her what the problem was. She complained that the program she used to reroute calls and so forth just wasn't up to scratch. She had requested improvements or replacements several times but the IT guys had done nothing. So Bloomberg went up there and told one of them to do the receptionist's job until the problem was fixed. Two days later she had the program she wanted.

Apocryphal or not I think that story says it all. It sounds like you don't have time to do two jobs but if you don't test as you go, unless it's a simple application or something which has been incredibly well planned, I reckon it'll cost you time. Read everything over at www.joelonsoftware.com if you haven't already. In fact read it twice. It's a great site for programmer's looking to improve their GUI designs.

bonkey

Originally posted by Morphéus
So tell us all how you do the above?

Mostly, I get a project that I've already written, and steal as much out of it as possible. Over time, I evolve better ways of doing things and modify the code from project to project.

I basically go mostly with massive amounts of code re-use. When I'm really lucky, I get to add a student to my resource-list and get him/her to do a lot of the repetitive stuff (i.e. "here's how this database table was coded as a business object. Now you go and go these other 20 tables, and call me if there's anything thats not identical in approach that you don't fully understand")

As for documentation...I fit that to what the customer needs. WHen left to my own devices, I work off the XP principle of "who's going to read it". If the answer is "no-one but me", then it gets written - at most - as a comment inside the code.

I currently have this structure floating about in my head for a set of objects/components which will basically give me the entire application once the business classes are written. I also have an idea of how to automate the generation of most of the business classes from database tables, using customisable code-templates (so it doesn't just fit my needs and wants).

Oh, and I've a project coming up where I need to write a report-generator, which I'll be able to hook in nicely for auto-generating "basic" reports (again, to customisable templates).

If I ever get around to writing all of this, it'll make such projects much easier....but what are the chances of that...

jc

Hobbes

I start by asking the end user what they want. Not what I think it should be like.

Typedef

I start by killing middle management.....


after that, real work can get done

Syth

First I drink 3 litres of coke. When I hit a sugar high I sit down and have a coding blitz till my body overcompensates for the sugar rush and I'm almost comatose. Then I sleep for 2 days. When I wake up I do it all again till I'm done.

watty

Hmmm,

A BIG question.

After nearly 50 years of High level language availability and 30 years of GUI front end, Colleges still havn't figured out how to teach this in a 4 year course.

Any idiot can learn a programming Language. In about 1 month to 6 months.

Naturally talented programmers can learn "Programming" in about a year and get expericenced in about 4 or 5 years. Then they can learn any arbitary new programming Language in a few days, a week max.

A very few of the actual programmers (not folks that simply learnt a programming language), are good at designing new interfaces (GUI) or systems or databases (all different design & programming skills). No-one knows why.

There are LOTS of methodolgies for good Design and Documentation. Most of them work for good programmers. They don't work much for those that have only learnt a language.

Testing is good, important and required. Testing and observing real users is mandatory. However you can't test in Functionallity, Security, Reliability etc, only DESIGN them in.


I know this is depressing and it is why even with Java, C++, C#, OOP and suchlike software has not improved. In fact much software is POORER than 20 years ago because the systems are bigger and more complex and less understood. The really bad SW of 20 years ago is mostly gone though.


Divide and conquer! If you can see the important elements of the project and split it into smaller separate projects (that require no knowledge of the insides of each other) then success is more likely and quality is higher.

Also the better and more complete design is before ANY software is written, the less bugs. Rememeber EVERY study suggests that at release date all SW has as many bugs still in it as where found during testing. If you spend more than 30% of project time debugging and getting rid of bugs as apposed to simply testing, then throw it away and do a new design. It will save time and money.


How do I know this?

I first learnt a programming language in 1967!

From 1979 I was getting paid to program.

Though I learnt another programming language in College in mid 1970s. it was during 1979 to 1983 I learnt programming.

I learnt C++ (before C) in 1987 in about 4 days.

I find letting users play with a quickly written simulation of a GUI quickly exposes logic errors of what the users want to do.

Never start writing code till you know all what it is meant to do IN DETAIL (whatever methodology you use).

I have written OSes, Vending machine SW, Industrial Controllers, Telecom ISDN SW, PC applications for DOS and Win 32 (Modula-2, C++, C, Occam, VB6, Pascal, Forth, and assembler).

Proprietary Database and SQL Server.

VB, C++ and Modula-2 and HTML frontends for Databases for microcontrollers with 2 lines displays, DOS, WIN32 and Web Browsers.


Be very scared!

mr_angry

Originally posted by Hobbes
I start by asking the end user what they want. Not what I think it should be like.

You're assuming that the end-user actually knows what they want. How many times have you consulted an end-user, only to find that when you actually deliver the software, they turn around and say "Oh wait. It only actually does about half of what we really need it to do". The only option, in my opinion, is continuous feedback with the customers / end-users, preferably on a daily basis.

Even with Bonkey's suggestion of using a tried & trusted spec for your front ends, I'd still recommend having a load of prototypes approved by the end user before releasing anything with your name on it. Of course, management will always try to get you to squeeze out the easiest, quickest generic interface possible, but sometimes you have to be strong and tell them you know better!

casper-

amen, mr_angry. Say it Louder!

watty

Yes I have turned down very valuable work because after several days consultancy it would be apparent the client did not know how they do what they do (They always did it, the same guys in the same parts of the process), or be able to explain it in a manner that would allow a work order / stock / material management etc system be designed.

Some jobs even SIX months after "sign off" you discover that a huge amount of time is spent updating paper records no-one told you about.

There is want the user says they want
What they really want
What would really benefit them
and what you think they are saying they want
and what you tink they need.

Unfortunately these are all often different!

bonkey

Originally posted by LurkingIcon
Never start writing code till you know all what it is meant to do IN DETAIL (whatever methodology you use).

What about the situation where the methodology you use says to start writing code as soon as you can see the simplest case, and worry about the detail later ????



jc

watty

Ah.. that must be the one method I don't use!

Depends what you mean by "detail"

I don't mean like which I/O address or what exact commands an I2C chip needs (The detail would be which 2GHz synthesiser chip to use and what it is for in the system), and how the user via GUI selects the Frequency or Channel to Receive or Transmit.

bonkey

Originally posted by LurkingIcon
Ah.. that must be the one method I don't use!

Depends what you mean by "detail"

I'm referring (somewhat obliquely) to development techniques such as XP. Here, a major concept is to not worry about good design up front, but rather to mercilessly refactor your code.

Basically, any time you have to re-address a piece of code, you reconsider whether or not it is still suitably designed. The idea being that code which is revisited often should end up having the most attention paid to it, and thus should slowly evolve into good design.

Code which is not revisited often is good enough the way it is.

A simple example would be designing a "database-abstraction layer" (or DAL). XP design says "don't bother". In fact, the first bit of DB code you write in the app will be in-line. The second bit may lead you to refactor to a slightly more generic design. Dont code in anything you don't need until you find you need it.

Every time you find that you need to revisit the code, think about how much refactoring would be useful/good. Is another if clause good enough, or should you redesign the entire method/class/library at this point.

There's a lot more going on around that (like how to ensure that all that refactoring doesn't break more than it fixes), but for certain types of projects it can be a great way to get things done.

One other great tenet of XP concerns documentation : If it won't be read, don't write it.

I just did a project recently for a client in a major Pharma company using this approach. The code was internally commented, and that was the sum total of documentation. Everything else was done "on the fly" - meeting the client, seeing what he wanted (which was hand-wavingly vague other than "we want to automate this" at the start), and giving him a basic idea of what we could try within 3 days. Thereafter, I had a new build for him every second day at most, which we discussed mostly over the phone (cause we are in seperate cities) rather than by email. We stopped the development when he felt he had enough functionality for this phase.

End result - client was deliriously happy with what he got, and I was equally delighted to have avoided so much bullsh1t paperwork which only would have gotten in the way of the development anyway

Technically, the internal design is only OK, but thats because it evolved to what it needed to do. I've since copied/pasted large chunks of it into another app, and refactored it some more there....and its looking prettier and prettier all the time.

jc

Unpossible

I have a number of old lab assignments and a few major projects, I simply use pieces of these, adapting them as I need to. Hopefully learning as I go along

watty

Originally posted by bonkey
I'm referring (somewhat obliquely) to development techniques such as XP. Here, a major concept is to not worry about good design up front, but rather to mercilessly refactor your code.

jc

Perhaps this is why I'm encountering systems with basic flaws in the areas of usibility, fit for purpose, security, performance, scaleabiility.

All these things MUST be designed / specified / understood before considering code at all.

Code is NOT the design, it is the implementation.

I'd agree on the documentation. Wrting documentation AFTER coding is a waste of time. It can only be done before coding and of a different sort inline.

C++ and C# need a lot more inline documentation than say Modula-2 or well written VB6. Of course there is Modula-2 and VB that looks like badly written Fortran or ultra-terse K&R C. (Actually most amatuer / hobby VB looks like bad Fortran)

Occasionally I even encounter C++ that looks like the author apprieciates that Humans, not just compilers will read it and who may even understand Barnje Strustrupp.

Imaging someone else reading the code. After 6months break, Yourself will feel like somebody else.

bonkey

Originally posted by LurkingIcon
Perhaps this is why I'm encountering systems with basic flaws in the areas of usibility, fit for purpose, security, performance, scaleabiility.

I disagree. Under the XP design mechanism, anything you would perceive as a basic flaw should be refactored (i.e. redesigned and/or recoded) as soon as it is seen to be flawed.

If there are still basic flaws, then someone hasn't done their job right in terms of implementing the methodology, let alone in terms of what they've been designing.

In fact, one major purpose of XP is to give you the freedom to address these problems without some jumped-up project manager telling you that this component is fine because it was written according to the design, and that its too late in the day to be changing the design because it would be too big a job.

Lets not also forget that many basic flaws come from simple lack of ability on the part of the programmers, and in such cases there isn't a methodology in the world (apart from "fire them and hire someone new") which can solve it.

All these things MUST be designed / specified / understood before considering code at all.

I disagree. That may be the methodology that suits you best, but it is not a panacea for all programmers.

Recent studies (can't remember where I read them though) show that there is no predominantly successful methodology. Each implementation of each one typically follows one of two classic paths :

1) Massive cut in productivity. People push through this, and stick with it, until modest gains are eventually made.

2) Massive cut in productivity. People push through this, but take shortcuts for various reasons, ultimately discarding the methodology as bogus because it never brought any gains.

There is no methodology which is the most suitable to every project, nor to every programmer, and personally I'm highly skeptical of any programmer / developer / manager who insists otherwise.

Typedef

Bonkey, your words of wisdom give me hope for the future.