74

I very often work in such projects, and the answer is a resounding YES, and as early as possible. People find it much easier to criticize improve some draft than to come up with a solution from scratch. So I start drafting early for two reasons: Give the matter experts an impression on how the information could be presented. Show my current understanding ...


39

Mockups are fantastic and there is no reason a dev shouldn't do them. (It can even be handy for a dev to do a rough draft of a UI layout even when you have UI designers on the project.) I highly recomend you don't make mockups that look like actual screens. If you share these with end users that often focus on things that don't matter like colors and ...


23

I can't speak for all functional programmers, but those I know all start out by writing the type signatures of the top-level functions, then as they need more detail, they write the type signatures of the helper functions, and so forth. This works because of the lack of side effects in functional programming, so functions are all specified in terms of only ...


23

Both are "standard". The first picture as per UML specs is Structured Activity Nodes A StructuredActivityNode is an Action that is also an ActivityGroup (see sub clause 15.6) and whose behavior is specified by the ActivityNodes and ActivityEdges it so contains. Unlike other kinds of ActivityGroup, a StructuredActivityNode owns the ActivityNodes and ...


22

The benefit of modeling software systems vs. all in code is: I can fit the model on a whiteboard. I'm a big believer in the magic of communicating on one sheet of paper. If I tried to put code on the whiteboard, when teaching our system to new coders, there simply isn't any code at the needed level of abstraction that fits on a whiteboard. I know the ...


19

The design phase is a vital part of the software development process; if you cannot design software, you cannot develop software, and shouldn't be calling yourself "software developer" ("programmer" would be more appropriate). However, designing software is not about diagrams and flowcharts. It is about figuring out solutions to a given problem on an ...


19

The UML standard defines over a dozen different diagram types, as shown in this handy chart: Source: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg See also Figure A.5 The taxonomy of structure and behavior diagrams in the UML 2.5 spec. Note that this is an example of a class diagram, with is-a subtyping relationships between ...


19

Discoverability Its absence plagues many organizations. Where is that tool that Fred built again? In the Git repository, sure. Where? The software pattern that comes to mind is Model-View-ViewModel. To the uninitiated, this pattern is a complete mystery. I explained it to my wife as "five widgets floating above the table talking to each other via some ...


17

Primitive Obsession is using primitive data types to represent domain ideas. The opposite would be "domain modeling", or perhaps "over engineering". Would you create a DateOfBirth object and a Salary object? Introducing a Salary object can be a good idea for the following reason: numbers rarely stand alone in the domain model, they almost always have a ...


16

You cannot look into the future - accept that. So better go ahead with a simple, but sufficient solution for today, and add more complexity when you know the requirements, not beforehand. If you invest too much design efforts into things which you will expect to happen "once in few years", and you don't know yet how the precise requirements will look then, ...


13

I've no idea why Hospitals, Prisons, Nursing Homes, etc need their own classes. Nothing here makes me think they do. Why aren't these simply different instances of InternshipProvider? Not everything with a name needs to be a class. You need polymorphism if a Hospital needs the same method to have a different implementation than a Prison. Otherwise, these ...


11

If a nucleotide has no significant behavior, and if its type information can be represented compactly (for example, a single character), then it doesn't deserve a separate class at all. Simply represent each nucleotide as a character (or whatever). If, however, a nucleotide has behavior, then I would model this with singletons, one instance per nucleotide ...


11

I had to deal with this a couple times. The first time I used option 2 (events) and as you said it became really complicated. If you go that route, I highly suggest you need very thorough unit tests to make sure the events are done correctly and you're not leaving dangling references, otherwise it's a really big pain to debug. The second time, I just ...


11

Yes, absolutely. Don't let someone else tell you how to do your job. And you are right, it's very much like doing UML for your data model. Assuming you are a developer, your job is to deliver quality software. If mockups help you do that, then that's part of your job. Do low fidelity mockups -- don't make them look like real screens. You'll waste too much ...


11

What is a domain expert ? When you develop software using Domain Driven Design, the primary focus should be on the domain model, that is a representation of the domain in which the software will be used. Let's take the example of an accounting software. The domain is accounting, and to build your domain model, you need to identify domain objects (e.g. ...


10

The rules of thumb I use are: Try not to assume any max size. If you must assume a max size, look for any standard regarding the field. Email for example has a max size of 256. Phone numbers have standards that differ depending on scope. If you must assume max size, and you have no standard to go by, pick something ridiculously large and then assume ...


10

When designing "a new screen", you want to discuss the rough idea of the UI first with a user and/or your colleagues. You cannot discuss this with a user "in code" or "in UML", that simply does not work (it won't even work between programmers). And you should expect that you need to throw away your first two or three scetches, or at least rearrange the UI ...


10

The best way to approach these sorts of problems is incrementally. Don't get frustrated and propose wide, sweeping architectural changes. Those will never get approved, and the code will never improve. That's assuming you can even determine the correct wide, sweeping architectural changes to make, which is unlikely. What is likely is that you could ...


9

Planning is critical, but as the famous strategist Carl von Clausewitz warns No campaign plan survives first contact with the enemy So its not a huge waste of time for planning how to initially attack the problems. But likely a waste of time for documenting your code for future programmers. To use a military metaphor, you need a battle plan, but you ...


9

XP doesn't explicitly call for the creation of a model, but it doesn't say that one should never be produced. If developing a model helps you to build and then document your system, it should absolutely be done. The difference is that Agile Modeling has a different focus than system modeling in a plan-driven environment. In fact, the Agile Modeling site even ...


9

I think UML diagrams can only be useful if they express something in a higher level of abstraction than your code. Writing UML just for the sake of writing UML becomes unneeded bureaucracy and makes the project and the code less adaptable to changes with no benefit whatsoever. For example, a UML class diagram showing all the classes on a package, with all ...


9

When I have to return to a section of code I've not worked on for a while, I have difficulty remembering how it worked. I spend a lot of time reviewing the header files for the relevant classes and reading the comments I placed along the way in the source files. Imagine how the poor guy who comes after you is going to feel -- he doesn't even have the ...


9

I question the premise that languages are more and more expressive. With today's ASP.NET code in c#, I write at about the same level as I did when I wrote ASP code in Visual Basic. We still use c++. Javascript has added features but overall the language has not changed. Same with SQL. I think these other changes are more significant: Adoption of ...


9

The problem with your original code example, is that Orders breaks the encapsulation of _orders as you are returning the list. Cast that IEnumerable<Order> to IList<Order> and code outside the class can start modifying the contents. My guess therefore is that OrderCollection is used to prevent this occurring. It isn't necessary to do that though:...


9

You're right; the membership ID is not part of your Primary Key. That's why synthetic keys exist. A synthetic key is one that is automatically generated, either by you or the database. It usually takes the form of either an incrementing number or a globally-unique identifier. Synthetic keys are never re-used, even if a record is deleted. The good ones ...


8

When I implemented a History<T> class (a sorted list of date values associated with some data of type T, allowing for old values to be dropped when new one's come in and a maximum size was reached etc.) I did it as a wrapper class around SortedDictionary<DateTime, T>. Because this collection implements IEnumerable, you can use LINQ's extension ...


8

UML has value if team members collectively understand it and consider it a useful way of summarising and communicating design decisions. You don't need to know it all, just that subset that the team finds useful. Also, you don't need to draw perfect, polished diagrams. A roughly-sketched sequence diagram on a whiteboard or a class diagram in which classes ...


8

Recursive composition (or aggregation) is simply the composition or aggregation arrow looped back to the individual class. You can use the multiplicity notation to indicate any "can have" or "must have" relationships. Figure 8 of Scott Ambler's tutorial on class diagrams provides an image of this.


8

Wrong is a big word. The reason why you shouldn't put it in the DB, is because the vocabulary of (most) DB systems is incredibly limited. There is nothing about "SELECT", "INSERT", "UPDATE", "DELETE" that allows you to fluently express why something is happening and to what it is a reaction, in domain language terms. As to the second part of your question: ...


Only top voted, non community-wiki answers of a minimum length are eligible