There's a difference between exploratory programming and the final deliverable.
I don't think the GP is suggesting 100% of spec must be completed before the first line of program code is written. I think the implication is that there should still be a dividing line between the design portion (made up of think, code, rethink, recode) and the production development portion (also made up of think, code, rethink, recode). The dividing line does not need to be months, but design as a phase of a project should be considered differently (since it has different priorities) than delivery.
I think you’re both right. If you frame the original comment as “don’t write final production code without thorough modeling” it works both ways. If you want to counter with “well our non-final code always goes to production anyway!” You have a cultural problem that needs addressing.
Well, I disagree with you. However by "design" I don't mean figuring all the implementation details out ahead of time. It means looking at the requirements, what solutions already exist, and figuring out the most elegant way to string together what you have and fill in the holes.
Now, IMO, this design never means writing a spec. It means thinking through things however, from an architectural rather than implementation perspective. It means thinking through the larger problems regarding how the pieces of your program will talk to eachother before you begin.
Then when you start coding, the only design questions you have left to answer are those which involve the sorts of details you won't know in advance.
I meant more that you need to let the things you encounter during implementation drive the design. This is particularly relevant when requirements change (as they often do), but even if you can nail down the spec perfectly up-front, trying to design at that stage is still a mistake.
A common misunderstanding about software creation is that code is the desired result. Hence, estimates more often than not try to predict how long it'll take to write the code that produces a desired outcome.
However, in the end, code is just a very detailed specification of the design that produces a desired outcome. There's a reason why production is called production, after all:
Therefore, equating code written by a software developer with the final result is a little like equating an architect's blueprint with a building that was built according to that blueprint. The fundamental difference between those disciplines, of course, is that with software development most of the manual (as in: non-automated) work is done once the code has been written, whereas with construction the by far largest part of the manual work involved happens after the architect has created the blueprint.
On one hand, this is a problem of perception. On the other hand, though, it's quite understandable that customers don't want to invest the better part of the budget upfront, not knowing if the design will meet the requirements.
This is where agile management methods come into play. Those can be misused or, indeed, abused, too, but the idea of eliminating waste and adapting early is a sound one.
The best and lowest-maintenance pieces of code our team has written were carefully designed and thought out before a line of code was written. I'd say 20% of the actual work was coding, 30%/30% for design and testing and 10%/10% for requirements analysis and deployment.
However, often we know that we don't know how to properly design something and we start implementing too early. The end result is sth like: 50% coding, 30% testing and the rest is squeezed into testing, deployment and requirements analysis.
> The problem is it's still a fast-changing discipline, with the unknowns dominating the knowns. The biggest known is construction time: most disciplines have a construction/distribution period long enough that it can cover/buffer for variation in the design phase; in software, the construction/distribution period is nigh unto instant (compilation), so design can't hide behind any other phase. It's all design, usually entailing something significant designers have never dealt with before.
This: an estimate to build software before the development has started (even assuming that the business requirements are frozen) isn't equivalent to an estimate to build a building once the design is set, its equivalent to an estimate of how long it will take to design and build a building once some of the basic objective parameters are set (like how big the footprint it can have, how much office space it needs to provide, etc.) but before the actual design has started.
I don't think the quote suggests that a programmer would mentally design a whole system before writing any code. As programmers, we are used to thinking in problems as steps needing resolution and that's exactly the 90% there.
When you're quickly prototyping to see what fits better as a solution to the problem you're facing, you must have already thought what are the requirements, what are the constraints, what would be a reasonable API given your use case. Poking around until you find a reasonable path forward means you have already defined which way is forwards.
Although this sounds flippant, the design process is where unknowns should be uncovered. It is easier to change design before a line of code is written.
Design is precisely what is needed in order for the dev team to break down the projects into tiny chunks where nothing is unknown.
Your time estimates should always include time for research and design. The customer can sign off on what you're about to write at the end of that (whereas beforehand you give them a wild ballpark figure made by senior devs - not management!)
I have known developers who, given a moderately complex programming task, will complete it within a reasonable amount of time. The code will be correct with no more than the expected bugs, and the design will be OK as a stand alone piece of code.
The design will not be ingenious. It will not take other parts of the system into account. It will not have simple tweaks done in preparation of future design change requests, tweaks that would make the code no more complicated, but many times more flexible. The code will not be as eloquent or as simple as it could be. A slight alteration to the initial design would have greatly simplified the code and ensured against bugs.
Then there is the opposite side of things.
The programmer who understands the greater business needs of the product, and writes code in anticipation of what is to come. Not entirely abstract to the point of ridiculousness, but with proper hooks put in that will be needed later. A software engineer who thinks past the most obvious implementation to what sorts of implications different designs offer. A software engineer who creates eloquent and understandable systems.
Yes one can argue that proper procedure and design reviews can enable the OK developer to reach the level of the Software Engineer, but at what cost to overhead? 2x? 3x? How many meetings, how many discussions?
There is a huge productivity difference between even experienced developers. Denying that is purposeful blindness.
I don't know about everyone else, but I was always taught that analysis and design come before the implementation. It's not something you do in 10 minutes before you start making software.
you don't know what's gonna make the final cut though. Stuff like language creation is super early on in the process at which point you're trying to engineer a system for success.
It makes sense because you don't know what you're gonna end up with and overshooting is better than missing.
I think it was an extreme example but we didn't. The design phase is exactly when you should be formulating ideas and throwing away things that don't work. The theory is that this is easier to do before code is laid down. They were way too granular though so it was super painful even in design phase to get these design docs together.
I think the design phase in this instance required far too much detail. Some middle ground would probably be best imo.
I have seen this kind of problems many times in real life. By start writing design doc and prototype code from very beginning, you demonstrate effort and progress. You most likely get hold of the project and eventually deliver it along with all the incremental complexity during the process.
On the other hand, if you spend 2 months iterate through the requirements and alternative design choices, you are far more likely to come up better design, but your manager (or the entire company) would have no patience to watch you thinking in your head. As the result, I have seen software designs could have been 10x or even 1000x better, but most people prefer to get something out first (this is especially necessary for startups).
Another random comment is LoC per day. I worked at a few large companies. The statistics show the residual code is about 6-16 lines of code per business day per software engineer. A lot of time goes into design, debugging, testing, iterations, redesign, refactoring.
That's still not code first. It's always product-first, just with different timeliness. If you're working on a system that need to last, you should still optimize for the product, but over a longer time span. The code is just the means to the end.
But "activities" are not "phases". You are always trying to get the requirements right, the difference is that some people get them while coding, and others before even start designing.
I think it might be cause no one really knows what you're building until it's been built. Only until then (or even a little later) does the structure of the thing become apparent. Until you've got something most people agree is what everyone wanted, requirements are basically mush and so the code is too.
I don't think the GP is suggesting 100% of spec must be completed before the first line of program code is written. I think the implication is that there should still be a dividing line between the design portion (made up of think, code, rethink, recode) and the production development portion (also made up of think, code, rethink, recode). The dividing line does not need to be months, but design as a phase of a project should be considered differently (since it has different priorities) than delivery.
reply