Well, I’ve been so busy lately that I’ve almost forgotten what I do when I have spare time [ ] ... but this week has been slower, finally, and my Software Engineering final is tommorrow morning, so after that, I’ll be finished for a week (I’m actually going to go on vacation from the computer for a week, starting Sunday).
When I get back, it’s the beginning of a new quarter at RIT and I’ll be back in class, but at least for a couple of weeks, I won’t be buried so deeply I won’t have time to think.
And this is what I’ve been thinking about:
The current crop of Windows™ replacement shells have all been developed following what amounts to an opportunistic approach to development. That is: someone had an idea for a shell, and just started coding. When they were happy with it, they released it to the public. And then, someone had another idea for that shell, and just started coding. When they were happy with it, they released it to the public. And then …
Well, you get the picture, right? The point is that I can’t really say that I’ve seen anything out there in alt-shell world that resembles a design document, or a software requirement specification, or even a long-term plan. And as I’ve been learning more and more about proper software design, I’m starting to think more and more about how much easier it would be to work with the geoShell team if we had a specified vision.
Eikonos and I have been talking about possible futures for geoShell, in light of previous possibilities and what hasn’t become of them. Actually, all the talk has me fairly pumped, but every time I look at the current geoShell source code I get discouraged. It’s just a mess, the result of years of iterations of the opportunistic approach to feature management. In fact, the ramen-noodle-like state of the source code is the number one reason cited by developers on our forums for not adding features or fixing long-standing minor annoyances.
So it’s back to the drawing board.
I think it’s time to reconsider a clean start, despite all it’s drawbacks. That might actually mean finishing R6, which has a very nice design. Or picking up raptor again (which matrice64 has actually been slowly working on all along). I’m not sure yet if those are options, or if we need a complete break and the XML window-messages of cobalt … or what. But the one thing that is clear is that geoshell development is slowing down and will probably stall altogether if we have to keep working with the current code base.
I want to put forward some core values for consideration in this process:
- An official development model, incorporating the notion of:
- Initial high-level analysis: without over-thinking the details, design before we code!
- Phased-release schedule, with initial partical-content releases leading up to a ‘stable’ release, followed by possible patch-releases
- Overlapping development cycles, with source-control branches for integrating patches to ‘stable’ releases
- Technological/Implementation prototypes which are the minimal amount of code to demonstrate the feasability of an approach, and are always thrown away rather than evolved into the final product
- Expressly state the use of design patterns when appropriate. E.g.: Observers, Singletons
- Expressed Design Goals:
- Divide and Conquer. We shall split the shell into small parts (the core, many services, many plugins) which can be replaced without needing to change other parts
- Reduced Coupling. We shall avoid the trap of ramen-code and the multiple interdependencies between supposedly separate modules, which makes the current R4 source code nigh impossible to comprehend.
- Increase Abstraction. Design in an object-oriented fashion and hide the details of functionality as much as possible. This goes along nicely with the concept of “Facades,” superclasses, and pre-set interfaces for plugins and services.
- Increased Reuseability. Generalize whenever possible so that components can be re-used. If we design the data-model sufficiently well (R6 does this superbly) we may even be able to design plugins as display/interaction “controls” which can display data fed to them by any service, and return actions.
- Reuse existing code when possible. Clearly it will be difficult to even find all the parts of some of the code now in GeoShell, but whenever it’s possible we should actively reuse code from R4 (and even R5/Raptor and R6) since, for instance, the system tray service is finally just about working perfectly.
- Design for flexibility. We will start with a settings service, and nothing from the window-sizes to the captions of windows will be hard-coded if it can be read in from a setting. Reducing coupling will allow a maximum level of flexibility by allowing us to test new ideas by simply creating replacement components.
- Avoid obsolescence. We will support Windows 2000 or better. We will not use undocumented or obsolete API’s except under the direst of circumstances.
- Use some agile methods
- We will plan our releases in small increments
- We will design for testability. We will even attempt to do automated unit tests. (This is a hard sell, we shall see what the dev team thinks).
- We will design defensively. We will not trust future developers to use methods and components the way we expect, and will expressly test inputs. We will try to design a crash-proof core which can survive even the most violent death of one of it’s plugins or services.
- Did I mention reuse?
- Implement better methods for tracking bugs, requirements, and features.
- Recruit a documentation team for beta testing!
There’s so much more that should go here, but it’s getting late, and I have a test in the morning (did you know 7 o’clock actually comes twice a day, just like 2 o’clock? [ ] ).
Similar Posts:
- None Found
If nothing else, I applaud your realization of what is necessary. You have accomplished no small feat in expressing (quite clearly, IMHO) your thoughts in this post.
That said, you’re suggesting that an effort be made to embrace a methodology that most professional (read: money-making) development shops have a hard time sticking with for any significant amount of time. One common reason that is oft-heard with regard to the stagnation of shell development is the perpetual “lack of free time” with which those who are capable of contribution are afflicted. You would have to agree that the adoption of the described methodology… never minding the scope of the project itself… would require significantly more time than the so-called opportunistic approach. Where is this time going to come from? If it must be volunteered by those who claim a “lack of free time,” what is their motivation to sacrifice that which they don’t have?
Personally speaking, I became involved with the shell development community because, ultimately, I was not satisfied with the environment in which I worked as a programmer. I had sugar plum dreams of fostering the Utopian development environment in the context of an Open Source project. What I came to realize, however, is that 1) IMHO, it’s not possible and 2) I was cheating my employer out of the potential that they were paying me to realize/develop. Since permanently abandoning the Open Source community… more specifically, the alt-shell community… I’ve redirected my efforts and ideals toward improving the development shop with which I’ve worked for 8 years now. I can’t even put into words the effect that it’s had. I wouldn’t trade the company or the guys that I work with for any other opportunity in the world. We’re that good. And it has nothing to do with me as an individual, but rather it has everything to do with all of us catching the same vision and making the same concerted effort to make it happen.
The point I’m trying to make is that while it might be possible to do what you’re talking about, you need to answer 2 questions: 1) Will I have to withdraw the effort that it will take to accomplish said goals from my employer, family, or friends? 2) Is it unrealistic to assume that an appropriate number of other people will be able to put forth the same sustained effort?
If you have to answer “yes” to either of those questions, you really should be asking “Should I?” rather than “Could I?”
I wish the alt-shell community well, but I think it’s incredibly unrealistic to expect it to be anything other than an “opportunistic” hobby.
Hi Jason! Long time …
Yeah, I realize what I’m talking about is a lot of ‘organization’ time … and as of right now, I haven’t been coding (on geoShell) at all for a few months until the last week or two. And then of course, there’s the fact that I have a baby coming …
However, I think I can easily say this much, at least:
All in all, I feel pretty good about it. Of course, all that could change in May, when the baby comes, or half-way to May, when I hit the huge ammount of schoolwork which usually swallows the last 4 or 5 weeks of my school quarter.
Oh, and P.S. ... I’m going to add more fluffing out of my thoughts when I get back from vacation, but part of the discussion is over on the geoShell board, where I’m about to answer another post almost as thoughtful as Jason’s … http://www.geoshell.com/board/forum_posts.asp?TID=1264
Jaykul: well said, as usual.
Though I do more of the coding now, I still consider you the manager of the project. You’re much better at the public relations and organizational side of things, and besides I’d rather just code.
Jason: you raise an important point. GeoShell does take time away from coding that I could otherwise spend working, but since in my professional work I mainly code back-end database related apps GeoShell gives me a chance to write fun (read: GUI) code for a wider audience.
Regarding the future of the shell: Though it means starting all over, I’d rather start from the design document stage. I don’t have any time invested in R6 and that’s a factor, but I also think a design doc is critical. The other reason is that a configuration system is also critical and regedit is not user-friendly enough. That’s why “config system” is the very first item on Cobalt’s Basic Considerations list. The cobalt design is far from complete and I want to work with any interested devs to come up with a solid design.
To both Joel and eikonos, I wish you guys the best. You really do have some good ideas.
I will caution you both, however, that the one thing that a software development course does not teach you is the one thing that will kill a project before it even gets started: attempting to do too much in too little time. To borrow someone else’s conclusion (albeit one that I strongly agree with), it takes ~10 years for a software product to really come into its own. There’s no reason why GeoShell is/should be any different. This point is even more poignant if you’re talking about starting from scratch.
Anyway, I’ll definitely be following this effort/project – I would love to see the R[0-9]+ curse broken.
For some reason, the 10-year article was not properly linked. It can be located @ http://www.joelonsoftware.com/articles/fog0000000017.html.
Sounds fantastic! Does have worrying undertones of similar announcements surrounding R5 and R6 (like many others, I’ve been lurking around since R3) but still sounds the right way to go. Modular components were one of the driving factors behind Cloud:9ine in its heyday but you’re absolutely right – design it well and it’ll work forever; design it badly and you’re doomed from the start.
I’m (still) no C/C++ coder but any help I can provide, it’s yours. Is there an IRC channel open for discussion on this?
cm
ps, Hi Jason!
Jaykul: By no means is it my goal to throw water on your fire, but let me share with you from experience that having an addition to the family most definitely amounts to LESS (in my case, much less) time on the computer for open source development. Either that, or you have to contend with an angry wife!
Having said that, I still think it’s possible to continue OS development (since I seem to be doing so aptly enough with my own projects, although at a rather slow pace).
I support your effort to do things “the right way” (whatever that really means). It’s something I strive for in life in general, but also, in particular, in my computing life.
Would it be too much to suggest doing it in Ruby? (grins widely, ducking for cover) Just kidding.
Hey munkie, yeah, we’re in #geoshell and #geodev on freenode ( irc.geoshell.org ). And Pistos: yeah, that’s too much. [
]
I found all the comments interesting and the philosophical reasoning clear. At 51 there are more years behind than in front, as a result prespectives have changed. I have no less energy or love for coding now than I had in 1976, only now it all has to count. Back when I could “afford” to spend all my “free” time coding and developing my own projects without regard to my employers interest, it consumed countless hours on my personal interest. Now every line is directed to a customer or potential product. All that said why on this forum?
Well after all these years of coding (most industrial systems for Fortune companies) and as the CEO of a public company “my” time is NEVER my own. 24-7 belongs to the shareholders. I would like to offer a few comments about strategy from an employer’s perspective remembering that my clients too are employers.
Windows (since we are talking about Shell replacements) is the cullmination of 30 years of code that has everthing that has ever been invented wrapped into a system that works very well all things considered. But it still has the hobbiest flavor in some areas, games, paint, and all the stuff tacked on by the special interest vendors. In 99.5% of the time in the industrial world we had to strip the system so that it could be “contained” in the hands of the workers. In other words we want, as employers, productivity from the tools not playtime. So replacement shells have been around a LONG time. Developed for specific purposes to accomplish very pin-point goals in a larger product delivery these shells captured the hobby computer and turned it into a machine for production. This is waht an employer wants.
Now I am here because we are back at that point where we need a very specific shell for our clients and I am looking for a code base to acquire that will allow us to build point specific shells. Employers want employees to work while at work – surfing or gaming. The employers I talk to would gladly put a room full of computers in break-rooms and public areas if they could have their desktops or laptops used for the purpose intend namely profit. You would never expect a computer attached to an MRI to be used to anything other than MRI stuff they why is the receptionist free to spend 30% of her day surffing?
Why don’t you guys use your vast knowledge and energy to develop a very basic shell. Administrators should have access to the full Windows shell and thus all the internals – everybody else needs a working platform that is job specific – Active Directory. Think about it, don’t try and re-train all the staff on some new and flashy interface, turn-over is too high and training is too costly. Microsoft spent millions in usability test to find that the “start” button is the best invention ever in the use of a computer. My clients need employees to be able to walk into the office and be trained in 30 minutes to do their job (think cash register here). Read the book – Don’t Make Me Think and you will have an understanding.
Now does anyone have any code? Naturally since the name of the game is money I am looking for a short cut rather than pay my developers for six months to develop something when it might be out there.
Most likely I will never find this forum again – that happens when you are spending your Saturday in the office working while all the employees enjoy their free time. I would like to hear if anyone has something to share though. I perhaps can offer some guidance on the directions you might take – not that it is any better than anyone else’s only it would be free.