The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Make me a better software developer
AlphaSnow
Registered User regular
Registered User regular
I'm in software development, I have around 2 years of commercial experience and I was unfortunately laid off recently. While I hunt for another job, I thought it'd be a good opportunity to tighten up my skill set and try to patch up some weaknesses. What I'd like is suggestions on the best way to do that.
I'd say I'm a fairly competent developer, but I believe that I have a definite problem in creating viable designs in a timely manner. For instance, I work as the primary developer on a custom MUD engine in my spare time with some friends. We identified the need for some kind of scripting system, so I went out and did the research into different solutions and decided that Lua would be best suited to our engine. I became familiar with the language, the API and wrote a few small test programs and researched existing solutions until I felt comfortable with it all.
Then when it came to actually designing the system itself, defining classes, their interactions, composition, abstraction and so forth. I pretty much stopped dead. I can think of plenty of different ways in which it could be implemented, I might crank out a few use cases, some UML diagrams, I might even begin implementing the design then half way through decide I don't like the way it feels and go back to square one. This leads to a trial and error type method of development that eventually gets the job done, but isn't particularly efficient.
I see the same problem in my professional work, which obviously doesn't reflect well on me when the project manager wanted whatever I was working on yesterday. Does anyone have any suggestions on ways to address this particularly problem?
I'd say I'm a fairly competent developer, but I believe that I have a definite problem in creating viable designs in a timely manner. For instance, I work as the primary developer on a custom MUD engine in my spare time with some friends. We identified the need for some kind of scripting system, so I went out and did the research into different solutions and decided that Lua would be best suited to our engine. I became familiar with the language, the API and wrote a few small test programs and researched existing solutions until I felt comfortable with it all.
Then when it came to actually designing the system itself, defining classes, their interactions, composition, abstraction and so forth. I pretty much stopped dead. I can think of plenty of different ways in which it could be implemented, I might crank out a few use cases, some UML diagrams, I might even begin implementing the design then half way through decide I don't like the way it feels and go back to square one. This leads to a trial and error type method of development that eventually gets the job done, but isn't particularly efficient.
I see the same problem in my professional work, which obviously doesn't reflect well on me when the project manager wanted whatever I was working on yesterday. Does anyone have any suggestions on ways to address this particularly problem?
AlphaSnow on
0
Posts
I don't really have any advice, as estimating the time a project will take and actually completing it within that time is one of my big weaknesses as well.
However, if you don't get decent advice here, try asking in the programming thread: http://forums.penny-arcade.com/showthread.php?t=80078
I used to have a similar problem as well, but as I've "matured" as a software developer it happens less. One of the reason experience is so important is you start to get a much better feel for where you'll take your projects even before you finish the design. One other thing you should always do - show your design, even if it's not finished, to another developer you respect. Many times another pair of eyes will show you flaws or alternatives you would have missed yourself.
Larger software companies have people in positions specifically for this stuff, usually called something like "X Architect" where X is Systems, Enterprise, etc.
Some times I'll come up with this complex cumbersome design and then one of my coworkers will say " why not do it this way ? ". Where "this" way is some easy and simple design.
I know you don't have co workers, but see if there are any open source projects around? I heard the code to SQLIte is really solid and put together well. I think it's C++
There are surprisingly few good books on software design, and even fewer that aren't bound to a particular method, or that raise their heads above the programming-language level.
Design exists at many levels. There's conceptual design, when you're thinking in general about the sorts of basic capabilities you want and how they interrelate and you're sort of arguing among stakeholders and drawing on napkins. There's also architectural design, high-level design, and detailed design.
Some people think that architectural design is the same as high-level design, but I don't. I think architectural design is about whatever is most important in your system. Many high-level issues are also important issues, so that's why it's easy to get confused, but a critical algorithm or procedure might be so important that it's worthy of detailed modeling in the system's architecture.
Architecture is also important because, if done right, it lets you look at the system independent of implementation technology. For example, just because you're implementing in an OO programming language doesn't mean you have to build software in an OO style. Corollary: Just because you are implementing in an OO language doesn't mean you ARE building software in an OO style).
Many people use this for both good and evil: You can use it for good, because it means you can use that language to build software in a style that is more appropriate for your domain (which may incorporate and extend OO concepts). You can use it for evil because, as the old saying goes, "you can write FORTRAN in any language [1]." (Likewise, you can also write object-oriented software in C, if you want to and are careful.)
I say this because a lot of "software design" books focus really strongly on a specific style - particularly OO. There are plenty of other styles in which to build software - blackboard, implicit invocation, flow-based (e.g., pipe-and-filter), layered, virtual-machine style (e.g., strict layering), aspect-oriented, map-reduce-style, and many more. If you only know one way to think about designing software, you'll only ever use that one way (whether it's appropriate or not).
Good books on software architecture include this and this.
Once you've chosen an architectural style and constraints, you can then move on to high-level design, many parts of which may also become part of your architecture. Questions here: How should I break my system's functionality up into independent parts (e.g., components)? How should those components communicate (e.g., connectors?) How should concurrency be handled throughout my system? If my system is going to be distributed across multiple computers, how should functionality be partitioned among those hosts?
Lower-level design generally involves understanding all of the above, and then making the low-level decisions necessary to implement it. Here is where books on things like Design Patterns are valuable. Design Patterns will not help you design a whole application, but they will help you design specific small parts of your application. Refactoring is another code-level (re-)design technique.
Be warned, of course, that low-level design patterns and things like that are more context-dependent on specific languages and design approaches. Although the Gang of Four (who wrote the above-linked Design Patterns book) intended that the patterns be broadly applicable in OO languages and designs, people like Guido van Rossum have pointed out that things like dynamic typing and strong reflection in a programming language (like Python has) either fundamentally change the ways you'd solve the problems that the patterns are intended to solve, or eliminate them entirely. So, given an architecture, the low-level design decisions I might use to implement it in Java might be very different from those I would use to implement it in Python or Scheme.
Books on UML and the like aren't books on software design. They're books on how to write down and communicate designs you've already made. You can document both good and bad designs easily in UML. If you wanted to improve your writing skills (i.e., the ability to clearly communicate your thoughts through words), you wouldn't take a typing class. Note that UML is also biased toward both OO and low-level design, although it's ambiguous enough that you can use it for high-level and architectural design documentation if you use it right. You can also use it to document non-OO systems although, again, you have to be careful about how you do it.
Good luck!
[1] The general meaning here is that FORTRAN is a very early language and therefore has few features we would call modern - ones that might encourage better coding practices, for example. As such, it's sort of a "least common denominator" programming language. Many old-timer FORTRAN programmers "learn" a new language like Java or C# only to end up writing code in those languages that looks, for all intents and purposes, like FORTRAN.
I've already got a copy of Code Complete, maybe I should give it another pass as a refresher. I've just ordered Pragmatic Programmer, thanks.
I'm guilty of this, my language of choice has been C++ for years and I often have to remind myself to take advantage of specific language features not afforded by C++ when using other languages. Like Rhino mentioned, I've came up with overly convoluted designs in the past to have a co-worker have a look over it and go, “Why not just use reflection?” or similar. I'm at least aware of this, and make an effort to use the tools the language provides.
This particularly stands out to me, in hindsight I have only really worked with object orientated languages using object orientated design and implementation techniques. I imagine it would be a good idea to at least spend a week or two studying some new paradigms to try and broaden my views. A brief look at programming paradigms on Wikipedia provides quite a daunting list, could someone make some suggestions as to which they believe would be the most immediately helpful to study?
Both links appear to go to the same book, with the second link showing a random page preview from within the book. I've added it to my “to-buy” list and I'll pick up a copy when funds allow.
I also thoroughly recommend this. Whenever I met a new coder, or someone just joined where I used to work, I'd always ask them if they read that, and just pester them to do so. I'd go so far as to say I wouldn't employ anyone as a coder who didn't either have a boatload of experience, or had at the very least thoroughly read that book.
It takes a long time to learn that same stuff the hard way.
Gaah copy-paste fail. I fixed the link in the above.
Functional (LISP) or logical (Erlang) would cover two major paradigms. Another, less dramatic, option would be to do an in-depth study of a dynamic language like Ruby (using a book like Programming Ruby).