For a while, I've felt that writing good software must involve
at least three people: a coder, a user interface designer, and a
tester. However, most of the Perl projects I've worked on
professionally have been lone-wolf projects. A manager has said,
"Stephen, here's a hammer and some nails; build an ocean liner," and
I was off on my own. After doing this for a bit, I've come up with
a method of getting some of the benefits of working with a team
without adding anyone else to the project.
One of the main reasons that there must be multiple folks on a project team is that it's possible to know too much about the whole project. For example:
-
If a user-interface designer knows too much about the deep
internals of a project, she won't approach the code the same way
that an uninitiated user might.
-
If a tester knows where the questionable spots are in the
code, and that the more bugs she finds, the harder she'll have
to work to fix them, she may unconsciously neglect testing
those areas.
-
If a coder does user-interface design, the UI may get tied
into the code very closely, and modifying the code in the
future might become more difficult.
However, in a pinch, I've learned to avoid some of these
problems with a bit of self-induced multiple personality
disorder. (Multiple-personality disorder seems to be real, and I
don't mean to trivialize it by bringing it up here.) With a bit
of method acting, one can keep the designer's persona separate
from the coder's. The techniques are simple and subtle, and
probably many people use them without thinking about
it. Drumroll please... the techniques are:
Consciously switch roles.
When you've been coding for a while, and are switching to
testing, take a second to remind yourself that whereas before
bugs were bad things that you didn't want to see, now they're
good things that you WANT to see. Think of yourself-the-coder as
"that lunatic whose code I need to check." Don't let yourself
change user-interface requirements because it's a little harder
to code that way; think of how yourself-as-interface-designer
would yell at you if you did.
Keep phases distinct.
Work in different subdirectories depending on your role. Use
different tools. Put HTML in templates and use an HTML editor to
edit them. Automate your unit tests so that yourself-as-tester
can work alongside yourself-as-coder easily. Using different tools and environments for different jobs makes it easier to remember who you're supposed to be right now.
Finally, it's sometimes useful to think of yourself as the
manager of this little hallucinatory workgroup. Being the
imaginary manager can give you some much-needed perspective on
what you're doing, and can make it easier to give accurate
answers to requests for time estimates.
(Just don't be your own
pointy-haired boss...)
stephen
|
Re: Programming with Multiple Personalities
by dws (Chancellor) on May 06, 2002 at 18:31 UTC
|
One of the other hats you need to occassionaly wear on a solo project is "product manager". This hat is responsible for gathering, refining, and prioritizing customer requirements. This hat has a major vote in "what features do we build next" decisions, and is responsible for keeping the customer in the loop to verify that what's being built has business value to the customer.
Projects that lack this hat (or don't fill it effectively), risk spending a lot of time and effort solving the wrong problem.
You can wear this hat if you're on a solo project, but it's tricky. The great trap is that you'll hear the first half (or third, or two sentences) of what the customer is asking for, and immediately swap in your "designer" hat and start thinking solutions. This is deadly, since a customer almost never gives a complete story on first presentation. Locking on to the wrong target can lead to a lot of wasted effort.
| [reply] |
Re: Programming with Multiple Personalities
by andreychek (Parson) on May 06, 2002 at 18:54 UTC
|
A very intriguing writeup. Like yourself, I often find that I'm in a similar situation, needing to handle UI design, coding, and testing. Complicating the issue more, I also would find it useful to split up the coding into 2 roles. Are we coding the backend module, or the frontend application making use of that module? It is a luxury when all the backend modules you need already exist on CPAN :-)
Using different tools and environments for different jobs makes it easier to remember who you're supposed to be
I like this idea, and I feel I've been doing something similar, although a bit unconciously. This particular idea may be hard for some of those permanently glued to a particular editor. I personally happen to like vim.. and I think if I tried to edit a file without vim, I would litter that file with various command characters that I would be using had I been in vim :-) However, perhaps there's a way around that.
One method might be to set up your editor to use different colors, based on the filetype you're editing.
What I happen to do now though, is use a different desktop for each role. When I do coding, I always do so from within X, where I can have multiple windows, and multiple desktops (and my workplace even sprung for me to have a second monitor!). So, I pull up several Xterms, throw them all in one desktop, and I designate that desktop as my HTML editing desktop. I then do the same for each individual application I'm working on. Since I do a lot of work with Apache / mod_perl, I also use a desktop for monitoring the error_log for my code errors. Lastly, I have an army of browsers open to, at a moments notice, reload a given portion of the application. In all, I have 6 desktops, each spanning two monitors.
Of course, a setup like this takes a bit of memory, but these days, RAM is cheap.. 256MB of RAM is $75 over at TC Computers. So if your system is running out of RAM, it's your own fault for not splurging for more :-) At that same ssite, you can also get yourself a second 17" monitor for well under $200 bucks, or a 19" for just over $200.
Windows users, don't fret! Although Windows does not come with the ability to manage multiple desktops, there is a utility called XDesk which can do that for you.
Also, no matter what sort of setup you have on your computer. might I recomment a huge whiteboard to hang on the wall beside your system for your design work you're going to need throughout your applications development.
-Eric
| [reply] |
Do a little bit of everything or you'll in for "Redrum"
by monkscafe (Novice) on May 07, 2002 at 02:56 UTC
|
This article rocks Stephen! I could not have said it better myself.
But...
HTML editors are notorious for putting proprietary code (Go Live, Dreamweaver, and the worst offender, Word) in your HTML and thus makes it impossible to manage by hand. What if your office works all in PC's and they won't get you a Mac? You should be able to use the command line and a basic text editor. Basic HTML text editors with even a little color coding I suppose are OK, but Emacs or Pico have worked for me for nearly 10 years and I will probably never use the WYSIWYG editors because I can type/template pages faster than any designer I've ever met. Test in Netscape to make sure your pages "render" properly, (IE forgives most HTML code bugs) and you'll be set.
I'm the Webmaster for the largest aerospace pilot/tech training training firm in the world. I work almost exclusively solo, to borrow an industry term. I am a former Amazon.com Website developer, and the company seemed to think I could do it all myself and denied any hiring of assistants for me, which I could use for the busy work.
In in any given hour, I'm neck deep in Perl, CGI, SSI, Apache, BSD command line, Photoshop, ImageReady, FTP, SSH, Flash, HTML, SHTML, Javascript, Fireworks, and more. It's hilarious to see me work all over the map. I have a virtual screen config with 6 screens full of programs open.
Anyone who knows this business can sympathize, but I manage to do it and no one seems to realize I'm doing the job of about 4-5 people, including designer, Perl programmer, program manager, QA, and usability tester. My manager, a non-technical Director of Marketing, is finally realizing what's up and has been shielding me from all the inane requests that come through; she blocks people so I can work. That's a huge win.
My advice is to never concentrate too hard on just one thing in this business. I'm pretty good at all of the above listed things, and can carry a conversation with just about any "pro" in any of those categories, but no way am I GREAT or a STANDOUT in any one. I know Perl people who couldn't tell a JPG from a GIF. I know designers who look at me like I'm a nutcase geek when I try to talk Conditional SSI and with them.
But...
I can do each of the jobs they of ask me. Headcounts are down all over the place, if you can be all things to all people, you'll be the head that's spared.
All these silly personal betterment and business environment books say you should be a "team player" -- how can you do that when you're playing singles tennis? Or you're 1-1 with the goalie in a breakaway? Either you will score or not, the team has nothing to do with it at that point.
Creating your own team by building a small but potent Web building library, having friendly co-workers act as testers, and using OPEN SOURCE software will save you time, money, and keep your reputation highly regarded, especially by those higher-up managers who think you are a magician.
Back to the kitchen...
Head Chef
Monk's Cafe
112th & Broadway
New York, NY | [reply] |
Re: Programming with Multiple Personalities
by Anonymous Monk on May 06, 2002 at 18:57 UTC
|
When you do have to play all three roles (UI-designer, tester,
coder), the best approach is to do the UI-design first (on paper),
then write your unit tests, then write the code. In this way, you
risk the least cross-contamination of design and testing with the
actual coding. Obviously you still have to be conscious of your role
(don't think about implementation while designing the UI, just focus
on the UI). And, of course, it doesn't all have to be up-front. You
can do the same thing in an iterative fashion so long as you make
sure you follow the design,test,code steps in that order for each
component.
| [reply] |
|
|
Weird - I tend to do it exactly the other way around. First, I write a backend interface and document it, then I write tests (although I often skip this part) and when I'm done, I write a user interface (if any).
If you are going to use Windows, you know there is an API that you can use. How would you feel if you had to wait for someone to code stuff after creating a nice GUI? I see a GUI as a front-end to code - it's not the actual code. Code should be modular: if someone wants to write a different GUI, that should be easy and doable with the same backend interface. The user interface must not have much code: important things should not be part of the user interface.
I don't write a front-end for an application of which I don't know how it is going to work, and I refuse to write unit tests before doing the actual coding. If you don't write your code first, you're restricting yourself too much.
1. Code 2. Tests 3. User Interface, and then refine the code to help the interface, write tests as bug reports come in, and adjust the user interface as much as you want.
As for playing different roles yourself: it's the only way to have good communication :)
- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.
| [reply] |
|
|
I usually find that if you design too much of the system architecture before designing a tangible user interface or "this is what the end user is doing with the system", I never manage to discover the entire set of issues or problems to solve.
This also has to do with communication. The users can't describe enough of what they want by themselves, and they can't give feedback until they have _something_ to commment on.
Thus, "what should I build?" starts with the user and the user interface (not nessecarily coding, but prototyping and desiging it). Then you can deduce what you need to build it, and how.
Once I know what to build, I find it helpful to implement small features, one at a time, all the way through. Start with a real easy feature to get going. Then do a real difficult one to try to encounter as many problematic design decisions as possible as soon as possible.
/J
| [reply] |
Re: Programming with Multiple Personalities
by rinceWind (Monsignor) on May 07, 2002 at 09:58 UTC
|
stephen,
This is a truly excellent writeup. There are a couple of points I wish to add for completeness:
Don't forget documentation. The production of online help and manuals may be the responsibility of the UI designer, but I see this as a distinct role. Often software houses have come unstuck by neglecting this aspect of their product. It may me the best software in the world, but who will be able to use it without instructions in plain English (or French, Japanese, etc.).
Who is the customer? With any project of a reasonable size, it is doomed to failure if the customer is not involved at an early stage (remember the classic swing diagram). Even if the customer is merely involved in signing off the requirements document, that is better than nothing, and saves much legal heartache when it comes to project delivery time.
| [reply] |
|
|
